No habilites el debugging en producción (ASP.NET)

Tu jefe se queja de que tu aplicación esta lenta en producción y en tu PC vuela sin límites. Antes de colocar tu aplicación web en Producción, deshabilita el debugging en todos los webconfigs que tengas. Si no lo haces, esto provoca que tu aplicativo se degrade y exista un bajo rendimiento. Es muy recomendable para ambientes de desarrollo pero no para productivos.

Cuando el debugging está habilitado, las peticiones de ASP.NET nunca terminan. Es decir cuando lo ocupamos en un ambiente de desarrollo podemos realizar un buen debugging con Visual Studio por que sabemos que dicha petición tiene un timeout definido por nosotros y que desaparecerá cuando hayamos realizado otra operación o terminemos el debugging por puntos. Pero en ambientes productivos eso es fatal, las peticiones no pueden tener timeouts infinitos.

Cuando el debugging está habilitado podemos crear mas de 100 dlls compiladas (Librerias), como es esto posible?

Bien. Cuando una página .aspx, asax o ascx es solicitada por primera vez, ASP.NET las compila dentro de un assembly. Este assembly tiene un nombre de 8 caracteres como 3ks0rnwz.dll o similar y guarda las clases de la página actual (No guarda el Code Behind). Esta dll se guarda en una carpeta llamada:

C:\WINDOWS\Microsoft.NET\Framework\NoVersion\Temporary ASP.NET Files

El code behind es compilado aparte en una librería principal, independiente de las dlls que se copiaron en la carpeta anterior.

Entonces si tenemos habilitado el debugging, se creará una dll por cada página que sea solicitada por primera vez y estará en modo debug. Si tenemos 100 paginas web, tendremos 100 dlls.

En cambio si tenemos deshabilitado el debugging cuando se realice alguna petición en cualquier página de nuestro aplicativo web, ASP.NET compilará todo dentro de un gran assembly. Las páginas ascx se compilarán en un emsamblado diferente de las páginas .aspx y estas páginas .aspx son compiladas en grupos basados en otros archivos si incluyen UserControls. Si tu aplicativo tiene diferentes subdirectorios, la compilación se llevará acabo en cada uno de ellos de manera separada. Es decir al final de tener 100 dlls, podrás tener solamente de 3 a 4, de acuerdo a lo que te comenté anteriormente.

Es muy fácil de detectar con un memory dump que aplicaciones (App Domains, librerias) están siendo utilizadas en modo debug.

0:016> !finddebugtrue
Debug set to true for Runtime: 61b48dc, AppDomain: /MyDebugApplication
Debug set to true for Runtime: 1f50e6d8, AppDomain: /MemoryIssues
Total 16 HttpRuntime objects

En un ambiente productivo es recomendable deshabilitar el debugging en todos los web.configs, lo podemos hacer manual por cada web.config

<compilation  debug="false"/>

o de forma general a nivel servidor.

<configuration>
    <system.web>
          <deployment retail=”true”/>
    </system.web>
</configuration>

• Referencia KB: http://support.microsoft.com/kb/815157
• Referencia Web: http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

Saludos!.

Contadores de Perfomance para ASP.NET y sus recomendaciones

ASP.NET

Contadores Específicos de ASP.NET

Nombre Contador	Descripción	Recomendación
Application Restarts	Número de veces en que la aplicación se reinicia	Si este valor es constante dentro de la gráfica. Se debe de checar los siguientes puntos: Si existió una modificación en el machine.config, web.config, global.asax. Si existió una modificación en la carpeta Bin del aplicativo. Cuando el número de compilaciones (ASPX,ASCX,ASAX) excede del límite especificado en el tag <compilation numRecompilesBeforeAppRestart=/>. Revisar si el antivirus no está reiniciando la aplicación. http://support.microsoft.com/?id=820746
Requests Current	Número de peticiones ejecutándose.	Si este contador no baja del 100%. Se debe incrementar el número de la cola de peticiones. Por que si ASP.NET excede del número por default empezará a rechazar peticiones, mandando mensajes de 500 en el navegador. IIS 7.0 – Incrementar la cola en el registro de Windows. 1. Ir al directorio: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 2. Crear un valor de tipo DWORD (Decimal) con el nombre de MaxConcurrentRequestsPerCPU 3. Establecer el valor de 5000 4. Reiniciar el IIS (iisreset). IIS 7.0 – Establecer un límite de peticiones concurrentes a nivel aplicación. 1.- Ir a la línea de comandos, ejecutar como Administrador. 2. – Ir al directorio the C:\Windows\System32\InetSrv 3.- Colocar el siguiente commando en lugar de “Sitio Web” será el nombre del sitio web appcmd.exe set config "SitioWeb" -section:system.webServer/serverRuntime /appConcurrentRequestLimit:"5000" /commit:apphost IIS 6.0 – Establecer un límete de cola de peticiones en el Application Pool 1.- Seleccionar el aplicación Pool click derecho Propierties. 2.- Ir al tab Perfomance, editar la opción Request queue limit cambiar el valor a 5000
Request Execution Time	Número de milisegundos que se tomaron para ejecutar la última petición.	Si este contador está muy elevado, checar el web.config de la aplicación en el tag compilation, colocarlo en FALSE. Tener el modo debug habilitado tiene un gran impacto en el rendimiento de una aplicación ASP.NET, y sólo se debe utilizar en etapas de desarrollo. No se recomienda su utilización en aplicaciones en producción, o cuando se quieren tomar mediciones de rendimiento. <compilation debug=FALSE/>
Requests Queued	Número de peticiones que están actualmente en cola.	Si este contador está muy elevado se recomienda aplicar las mismas recomendaciones que el contador Requests Current
Requests Rejected	Número de peticiones que están siendo rechazadas.	Cuando rebasa el límite de cola permitido por ASP.NET puede ser por varias razones: Bajo rendimiento de SQL Server Cuando se incrementa el número de instancias de Pipeline (Buffers, Listas,Colas) Cuando degrada la utilización del CPU. El valor de este contador debe ser 0. Se debe revisar estos contadores, si tienen un número elevado: · Process\% Processor Time · Process\Private Bytes · Process\Thread Count · Web Service\ISAPI Extension Requests/sec · ASP.NET\Requests Current · ASP.NET\Requests Queued · ASP.NET\Request Wait Time · ASP.NET Applications\Pipeline Instance Count · ASP.NET Applications\Requests in Application Queue Se recomienda aplicar las mismas recomendaciones que el contador Requests Current y volver a realizar un trace de contadores.
Worker Process Restarts	Número de veces que el proceso aspnet_wp se reinicia.	Revisar si no existe un reinicio forzado dentro de las opciones de Reciclado del Application Pool. Revisar la configuración en el machine.config del tag ProcessModel. http://msdn.microsoft.com/en-us/library/7w2sway1.aspx

Saludos!.

Eliminando los Unhandled Exceptions ASP.NET en el EventViewer

Evento Registrado:

Event code:  1309

Event message: An unhandled exception has occurred.

Event time: 5/8/2011 4:40:56 PM

Event time (UTC): 5/8/2011 9:40:56 PM

Cuando se registran  advertencias de errores que no son administrados dentro de la aplicación, como se muestra en la siguiente figura:

Causa:

Existen excepciones que son lanzadas desde alguna .dll o webservice o dentro de la misma aplicación, que no están siendo administrados correctamente mediante un try – catch.

Ejemplo:

Librería (.dll) //En donde ocurrirá la excepción.

using System;
namespace Library
{
    public class Data
    {
        public static void Example()
        {
             throw new System.Exception("Error");
        }
    }
}

Página donde se consume la librería o webservice.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class _Default : System.Web.UI.Page
{
    protected void btnGenerateException_Click(object sender, EventArgs e)
    {
        Library.Data.Example();
    }
}

Al momento de llamar el método ocurre la excepción como se muestra en la figura:

Al momento de haber una excepción en la aplicación, el event viewer registra lo siguiente:

Recomendación 1: A todas las llamadas a los métodos colocar un try catch, ya desea dentro del mismo método o al momento de llamarlo.

Recomendación 2: Si dentro del aplicativo se utilizan variables u objetos que derivan de la interfaz IDisposable, es preferible utilizarlo dentro de un bloque using.

Referencias URL:

Utilizar using para objetos IDisposable.

http://msdn.microsoft.com/en-us/library/yh598w02.aspx

Implementing Finalize and Dispose to Clean Up Unmanaged Resources

http://msdn.microsoft.com/en-us/library/b1yfkh5e(v=VS.80).aspx

Referencia URL: http://ewebmx.com/2011/08/eliminando-los-unhandled-exceptions-asp-net-en-el-eventviewer/

Saludos!