Debug = true в web.config = ПЛОХАЯ вещь?

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

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

Ответ 1

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

Наиболее важные моменты, почему вы не должны оставлять debug = "true" :

Компиляция страниц ASP.NET занимает больше времени (поскольку некоторые оптимизации пакетов отключены)
Код может выполняться медленнее (поскольку некоторые дополнительные пути отладки включены)
В приложении во время выполнения гораздо больше памяти используется
Скрипты и изображения, загруженные с помощью обработчика 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" в элементе не является прямым противоядием отладки = "true" !

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

У вас много файлов в App_Code?
Вы разрешаете обновление сайта или публикуете его?
Если так часто обновляется сайт или существует процесс развертывания?
Что такое конфигурация оборудования?

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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