debug = true в web.config = плохая вещь?

Question

Мы видим много фрагментов виртуальной памяти и ошибок нехватки памяти, а затем она достигает предела 3 ГБ.

Отладка компиляции установлена ​​в true в файле web.config, но я получаю разные ответы от всех, кого я спрашиваю, устанавливает ли отладка значение true, приводя к тому, что каждая aspx компилируется в случайные области оперативной памяти, таким образом фрагментируя этого оперативной памяти и в конечном итоге вызывая нехватку памяти проблемы?

Answer 1

У Скотта Гатри (менеджера команды разработчиков ASP.NET) есть интересный пост об этом .

Наиболее важные моменты, по которым вы не должны уходить debug="true":

1. Компиляция страниц ASP.NET занимает больше времени (поскольку некоторые пакетные оптимизации отключены)
2. Код может выполняться медленнее (поскольку некоторые дополнительные пути отладки включены)
3. Во время выполнения в приложении используется гораздо больше памяти
4. Скрипты и изображения, загруженные из обработчика WebResources.axd, не кэшируются браузером, что приводит к увеличению числа запросов между клиент и сервер

Он также упоминает флаг <deployment retail=”true”/> в machine.config, который позволяет глобально переопределить флаг debug = "true" всех приложений, запущенных на компьютере (например, на рабочем сервере).

---

Обновление : развертывание веб-приложений с debug="true" все еще плохо, как вы можете прочитать в недавнем сообщении Скотта Хансельмана в блоге :

Вот почему debug = "true" это плохо. Серьезно, мы не шутим.

• Переопределяет тайм-аут выполнения запроса, делая его фактически бесконечным
• Отключение оптимизации страниц и JIT-компилятора
• В 1.1 приводит к чрезмерному использованию памяти CLR для отслеживания отладочной информации
• В 1.1 отключает пакетную компиляцию динамических страниц, что приводит к 1 сборке на страницу.
• Для кода VB.NET приводит к чрезмерному использованию WeakReferences (используется для редактирования и продолжения поддержки).

Важное примечание: вопреки тому, что иногда считают, установка retail = "true" в элементе не является прямым противоядием от с debug = "true"!

Answer 2

Флаг отладки должен быть установлен в false в web.config, если вам действительно не нужно отлаживать приложение.

Работа в режиме отладки может несколько увеличить использование памяти, но вряд ли это серьезные проблемы, о которых вы говорите. Однако вам следует установить значение false, чтобы устранить эффект, который он имеет, и посмотреть, сможете ли вы заметить какое-либо улучшение.

При запуске в режиме отладки сборка мусора работает иначе. Время жизни переменных расширено от фактического использования до области видимости переменной (чтобы иметь возможность показать значение в отладчике). Это заставляет некоторые объекты жить дольше, прежде чем они будут собирать мусор.

Компилятор не оптимизирует код при компиляции в режиме отладки, а также добавлены некоторые дополнительные инструкции nop, так что в каждой строке кода есть хотя бы одна инструкция, в которую можно поместить точку останова.

Создание исключения занимает значительно больше времени в режиме отладки. (Тем не менее, обычно код не должен генерировать исключения, которые часто.)

Answer 3

Это абсолютно может повлиять на память, просто взгляните на некоторые счетчики perfmon и проведите сравнение с обеими конфигурациями.

Если на вашем сайте много файлов, я бы больше интересовался диском io во временной папке asp.net.

Пара вопросов ...

1. У вас много файлов в вашем App_Code?
2. Вы разрешаете обновлять сайт или публикуете его?
3. Если да, то часто ли сайт обновляется или происходит процесс развертывания?
4. Какая конфигурация оборудования?

Почему бы не использовать несколько конфигураций?

Web.Debug.Config - включена отладка Web.UAT.Config - независимо от ваших предпочтений Web.Release.Config - Отладка отключена

Таким образом, вы можете минимизировать ошибки конфигурации регрессии, например, если разработчик регистрирует файл web.config с помощью debug = "true"

Answer 4

AFAIK "debug = true" не вызывает ситуацию, которую вы упомянули.

Я столкнулся с той же проблемой с приложением ASP.NET, которое создавало изображения на лету.

поэтому я думаю, что у вас есть проблема с нераспределенными ресурсами.

Если вы развернете свои aspx файлы с файлами code-behind на сервер. Он будет скомпилирован один раз, когда запрос придет в aspx. затем он будет сохранен в кеше, пока файл не изменится.

Answer 5

В производственных системах всегда устанавливайте Debug = false. Поскольку флаг предполагает, что это должно быть установлено в true только при отладке системы разработки.

Этот флаг не имеет ничего общего с проблемой фрагментации памяти.