Para confirmar lo que mi amigo Patrick MacKay explica en estos 3 artículos:
¿Por qué debo definir "debug=false" en web.config?, Parte I
¿Por qué debo definir "debug=false" en web.config?, Parte II
¿Por qué no debo compilar en modo debug?, Parte III
,quisiera mostrarles los resultados de la ejecución de test de stress sobre un sitio ASP.NET compilado en modo debug.
Me topé con un caso en el cual el sitio había sido compilado en modo debug y habilitado debug=true en el web.config . Claro no me enteré de esto hasta que me dijeron: "Pusimos a correr la prueba y no anduvo, hay un valor % Time in Jit que está muy alto". Y efectivamente estaba muy alto:
Noten que el contador % Time in Jit de la categoría .NET CLR JIT se mantiene constante durante 3 horas a valores altísimos. Los umbrales propuestos por Visual Studio 2005 para este contador son:
Warning: 25
Critical: 50
Según mi experiencia en una prueba de stress, salvo el primer minuto donde hay picos de hasta 80%, el valor normal no supera el 1%.
Si se fijan la cantidad de Requests/seg que la aplicación logró responder es 0. La aplicación Web está totalmente inhibida.
Una segunda corrida mas corta tratando de encontrar el problema arrojó el mismo resultado:
Estas mediciones confirman lo tratado en el artículo I, donde Patrick muestra como se sucede la compilación de un sitio ASP.NET al hacerse una petición. Excelente tratamiento de parte de Patrick al tema.
El debugging es solo para eso: depuración.