asp.net - studio - iis debug

debug=true en web.config=BAD thing?

Question

Estamos viendo mucha fragmentación de memoria virtual y errores de falta de memoria y luego llega al límite de 3 GB.

La depuración de la compilación se establece en true en web.config, pero recibo respuestas diferentes de todos los que les pregunto. ¿La debug establecida en true hace que cada aspx se compile en áreas aleatorias de ram que fragmentan ese ram y eventualmente causan problemas de memoria?

Answer 1

AFAIK "debug = true" no causa la situación que mencionó.

Me había enfrentado al mismo problema con una aplicación ASP.NET que creaba imágenes sobre la marcha.

Así que creo que tienes un problema con los recursos no dispuestos.

Si implementa sus archivos aspx con archivos de código subyacente en el servidor. Se compilará una vez cuando la solicitud llegue a un aspx. luego se almacenará en el caché hasta que el archivo cambie.

Answer 2

Absolutamente podría afectar la memoria, solo eche un vistazo a algunos de los contadores de rendimiento y ejecute una comparación con ambas configuraciones.

Si su sitio tiene muchos archivos, me preocuparía más el disco io en la carpeta temporal de asp.net.

Preguntas de pareja ...

1. ¿Tienes muchos archivos en tu App_Code?
2. ¿Está permitiendo que el sitio sea actualizable o lo está publicando?
3. Si es así, ¿el sitio se actualiza con frecuencia o hay un proceso de implementación?
4. ¿Cuál es la configuración del hardware?

¿Por qué no utilizar configuraciones múltiples?

Web.Debug.Config: haga que la depuración esté activada Web.UAT.Config: cualquiera que sea su preferencia. Web.Release.Config: la función de depuración está desactivada

De esta manera, puede minimizar los errores de configuración de regresión, como un desarrollador que comprueba un web.config con debug = "true"

Answer 3

El indicador de depuración se debe establecer en falso en web.config, a menos que realmente necesite depurar la aplicación.

La ejecución en el modo de depuración puede aumentar el uso de la memoria, pero no es probable que sea un problema tan grave como el que habla. Sin embargo, debe configurarlo en falso para eliminar el efecto que tiene y ver si puede notar alguna mejora.

Cuando se ejecuta en modo de depuración, la recolección de basura funciona de manera diferente. El tiempo de vida de las variables se expande desde su uso real hasta el alcance de la variable (para poder mostrar el valor en el depurador). Esto hace que algunos objetos vivan más tiempo antes de que sean recolectados.

El compilador no optimiza el código al compilar en modo de depuración, y también se agregan algunas instrucciones nop adicionales para que cada línea de código tenga al menos una instrucción donde se pueda colocar un punto de interrupción.

Lanzar una excepción lleva considerablemente más tiempo en el modo de depuración. (Sin embargo, normalmente el código no debería lanzar excepciones tan a menudo).

Answer 4

En los sistemas de producción siempre se establece Debug = false. Como sugiere el indicador, solo se debe establecer en verdadero cuando se depura un sistema de desarrollo.

Esta bandera no tiene nada que ver con su problema de fragmentación de memoria.

Answer 5

Scott Guthrie (gerente del equipo de desarrollo de ASP.NET) tiene una publicación interesante al respecto .

Los puntos más importantes por los que no debes dejar debug = "true" son:

1. La compilación de páginas ASP.NET lleva más tiempo (ya que algunas optimizaciones de lotes están deshabilitadas)
2. El código puede ejecutarse más lento (ya que algunas rutas de depuración adicionales están habilitadas)
3. Se utiliza mucha más memoria dentro de la aplicación en tiempo de ejecución
4. Las secuencias de comandos y las imágenes descargadas del controlador WebResources.axd no se almacenan en el caché, lo que genera más solicitudes entre el cliente y el servidor.

También menciona la bandera <deployment retail=”true”/ > en machine.config, que permite anular globalmente la bandera debug = "true" de todas las aplicaciones que se ejecutan en una máquina (por ejemplo, en un servidor de producción).

Actualización : la implementación de aplicaciones web con debug="true" sigue siendo mala, como se puede leer en la publicación reciente del blog de Scott Hanselman :

Aquí es por qué debug = "true" es malo. En serio, no estamos bromeando.

• Anula el tiempo de espera de ejecución de la solicitud para que sea efectivamente infinito
• Desactiva la página y las optimizaciones del compilador JIT
• En 1.1, lleva a un uso excesivo de memoria por parte del CLR para el seguimiento de la información de depuración
• En 1.1, desactiva la compilación por lotes de páginas dinámicas, lo que lleva a 1 ensamblaje por página.
• Para el código VB.NET, se produce un uso excesivo de WeakReferences (utilizado para editar y continuar con el soporte).

Una nota importante: al contrario de lo que a veces se cree, establecer retail = "true" en un elemento no es un antídoto directo para tener debug = "true".