ASP.NET Supervisión del rendimiento y cuándo alertar a los administradores

Artículo
06/24/2011

Thomas Marquardt
Microsoft Corporation

Actualizado julio de 2003

Se aplica a:
Microsoft® ASP.NET

Resumen: Describe qué contadores de rendimiento son más útiles para diagnosticar problemas de estrés y rendimiento en aplicaciones de Microsoft ASP.NET, qué umbrales se deben establecer para alertar a los administradores de problemas y otros recursos que se pueden usar para supervisar el estado de una aplicación de ASP.NET. (17 páginas impresas)

Descargue el código fuente de este artículo.

Contents

Supervisión de contadores de rendimiento
Supervisar el registro de eventos
Supervisión de los registros W3C y HTTPERR
Otros recursos usados para supervisar ASP.NET
Descripción de los contadores de rendimiento
   Contador de excepciones de .NET CLR
   Contadores de carga de .NET CLR
   Contadores de memoria de .NET CLR
   contadores de ASP.NET
   Contadores de aplicaciones de ASP.NET
   Contadores de procesos
   Contador de procesador
   Contador de memoria
   Contador del sistema
   Contadores de servicio web
Conclusión

Supervisión de contadores de rendimiento

Hay muchos contadores de rendimiento disponibles para la supervisión de aplicaciones. Elegir cuáles incluir en los registros de rendimiento puede ser complicado y aprender a interpretarlos es un arte. Este artículo le ayudará a sentirse más cómodo con estas dos tareas.

Como mínimo, se deben supervisar los siguientes contadores de rendimiento para las aplicaciones de Microsoft® ASP.NET:

Processor(_Total)\% de tiempo de procesador
Proceso(aspnet_wp)\% tiempo de procesador
Process(aspnet_wp)\Bytes privados
Process(aspnet_wp)\Virtual Bytes
Process(aspnet_wp)\Handle Count
Excepciones clR de Microsoft® .NET\# Exceps iniciadas por segundo
ASP.NET\Reinicios de la aplicación
ASP.NET\Solicitudes rechazadas
ASP.NET\Reinicios del proceso de trabajo (no aplicable a IIS 6.0)
Memoria\Mbytes disponibles
Servicio web\Conexiones actuales
Solicitudes de extensión de ISAPI\Servicio web/s

A continuación se muestra una lista más grande de contadores de rendimiento que son útiles para supervisar el rendimiento. Siempre es bueno tener más datos de rendimiento que no suficientes, especialmente cuando se experimenta un problema que no se reproduce fácilmente. La lista omite varios contadores de rendimiento que generalmente no son necesarios. Por ejemplo, los contadores de rendimiento de estado de sesión y transacciones solo son necesarios cuando se usan las características.

Se recomiendan algunos umbrales en función de mi experiencia con la depuración y las pruebas de ASP.NET aplicaciones. Puede buscar en este artículo "Umbral" para ir directamente a ellos. Los administradores deben determinar si se deben generar alertas cuando se superen estos umbrales en función de su experiencia. En la mayoría de los casos, las alertas son adecuadas, especialmente si el umbral se supera durante largos períodos de tiempo.

Supervisar el registro de eventos

Es fundamental supervisar el registro de eventos de los mensajes de ASP.NET y Microsoft® Internet Information Server (IIS). ASP.NET escribe mensajes en el registro de aplicaciones, por ejemplo, cada vez que finaliza el proceso de trabajo de aspnet_wp. IIS 6.0 escribe mensajes en los registros de la aplicación o del sistema, por ejemplo, cada vez que el proceso de trabajo de w3wp notifica que tiene un estado incorrecto o se bloquea. Es bastante fácil escribir una aplicación .NET que lee el registro de la aplicación y filtra los mensajes de ASP.NET e IIS, y activa una alerta (envía correo electrónico o marca un buscapersonas) si es necesario.

Supervisión de los registros W3C y HTTPERR

En primer lugar, habilite el registro W3C para IIS 5.0 e IIS 6.0 a través del Administrador de Internet Information Services (IIS). Este registro se puede configurar para incluir varios datos sobre las solicitudes, como el URI, el código de estado, etc. Examine el registro de códigos de error como 404 No encontrado y tome medidas para corregir los vínculos, si es necesario. En IIS 6.0, el código de subestado se incluye en el registro y es útil para la depuración. IIS usa códigos de subestado para indizar problemas específicos. Por ejemplo, 404.2 indica que la extensión ISAPI que controla la solicitud está bloqueada. Puede encontrar una lista de códigos de estado y subestados en el tema Acerca de los mensajes de error personalizados .

Novedades de IIS 6.0, solicitudes incorrectas o incorrectas y solicitudes que no pueden atender un grupo de aplicaciones se registran en el registro HTTPERR mediante HTTP.SYS, el controlador en modo kernel para controlar las solicitudes HTTP. Cada entrada incluye la dirección URL y una breve descripción del error.

Compruebe el registro HTTPERR de las solicitudes rechazadas. Las solicitudes se rechazan mediante HTTP.SYS cuando se supera la cola de solicitudes de kernel y cuando la aplicación se desconecta mediante la característica Protección rápida por error. Cuando se produce el primer problema, la dirección URL se registra con el mensaje QueueFull y, cuando se produce el segundo, el mensaje es AppOffline. De forma predeterminada, la cola de solicitudes de kernel se establece en 1000 y se puede configurar en la página Propiedades del grupo de aplicaciones en el Administrador de IIS. Recomiendo aumentar esto a 5000 para un sitio ocupado, ya que la cola de solicitudes de kernel podría superar fácilmente 1000 si un grupo de aplicaciones se bloquea mientras un sitio está bajo una carga muy alta.

Compruebe el registro HTTPERR de las solicitudes perdidas debido a un bloqueo o bloqueo del proceso de trabajo. Cuando esto ocurre, la dirección URL se registrará con el mensaje, Connection_Abandoned_By_AppPool, para cada solicitud en curso. Una solicitud en curso es una que se envió a un proceso de trabajo para su procesamiento, pero no se completó antes del bloqueo o bloqueo.

Puede encontrar detalles sobre el registro HTTPERR en el artículo de Microsoft Knowledge Base 820729: INFO: Registro de errores en la API HTTP.

Otros recursos usados para supervisar ASP.NET

Los contadores de rendimiento y los registros de eventos no detectan todos los errores que se producen y, por tanto, no son suficientes para supervisar ASP.NET. Recomiendo escribir una aplicación sencilla que envíe una solicitud HTTP para una o varias páginas y espere una respuesta determinada. Esta herramienta debe supervisar el tiempo hasta el último byte (TTLB) para asegurarse de que las páginas se sirven de forma oportuna. También debe registrar los errores que se produzcan, ya que esta información será necesaria para analizar el problema.

El Kit de recursos de IIS 6.0 incluye analizador de registros 2.1, una herramienta para analizar archivos de registro (registro W3C, registro HTTPERR, registros de eventos) y almacenar los resultados en un archivo o base de datos. El kit de recursos se puede instalar en Microsoft® Windows® XP y Microsoft® Windows Server™ 2003.

También puede escribir una aplicación que recopile datos de rendimiento, filtre el registro de eventos y registre los datos de clave en una base de datos de Microsoft® SQL Server. Es increíblemente fácil hacerlo mediante el espacio de nombres System.Diagnostics . Incluso puede supervisar los reinicios del proceso de trabajo mediante la clase System.Diagnostics.Process .

Para ayudarle a empezar, use el vínculo de la parte superior de este artículo para descargar código de ejemplo para varias herramientas útiles:

Código fuente para snap.exe, una herramienta de línea de comandos para registrar datos de rendimiento para procesos. El archivo Snap.cs contiene una breve descripción y explica cómo compilar la herramienta.
Código fuente para HttpClient.exe, un cliente simple que registra el tiempo de último byte (TTLB) para las solicitudes HTTP. El archivo HttpClient.cs contiene una breve descripción y explica cómo compilar la herramienta.
Código fuente para qqq.exe, una herramienta de línea de comandos para probar el esfuerzo de una aplicación de ASP.NET. Cuando se usa en combinación con un cliente de esfuerzo, como Microsoft® Application Center Test (ACT), esta herramienta asociará depuradores al proceso de trabajo y supervisará determinados contadores de rendimiento. Se puede ajustar para dividir en los depuradores cuando se degrada el rendimiento. El archivo qqq.cs contiene una descripción breif y explica cómo compilar la herramienta.
La página pminfo.aspx usa la clase System.Web.ProcessModelInfo para mostrar información sobre los reinicios del proceso de aspnet_wp. El historial se mantiene hasta que se detiene el servicio w3svc.
Código fuente para ErrorHandler.dll. Se trata de un IHttpModule que puede agregar a la canalización HTTP para registrar excepciones no controladas en el registro de eventos. Es mejor registrar errores en una base de datos de SQL Server, pero en el ejemplo se usa el registro de eventos para simplificar.

Otro paso sencillo es implementar Application_Error. Puede agregar el texto siguiente a global.asax e iniciar inmediatamente el registro de errores no controlado en el registro de la aplicación:

<%@ import namespace="System.Diagnostics" %>
<%@ import namespace="System.Text" %>

const string sourceName      = ".NET Runtime";
const string serverName      = ".";
const string logName         = "Application";
const string uriFormat       = "\r\n\r\nURI: {0}\r\n\r\n";
const string exceptionFormat = "{0}: \"{1}\"\r\n{2}\r\n\r\n";

void Application_Error(Object sender, EventArgs ea) {
    StringBuilder message = new StringBuilder();
    
    if (Request != null) {
        message.AppendFormat(uriFormat, Request.Path);
    }
  
    if (Server != null) {
        Exception e;
        for (e = Server.GetLastError(); e != null; e = e.InnerException) {
            message.AppendFormat(exceptionFormat, 
                                 e.GetType().Name, 
                                 e.Message,
                                 e.StackTrace);
        }
    }

    if (!EventLog.SourceExists(sourceName)) {
        EventLog.CreateEventSource(sourceName, logName);
    }

    EventLog Log = new EventLog(logName, serverName, sourceName);
    Log.WriteEntry(message.ToString(), EventLogEntryType.Error);

    //Server.ClearError(); // uncomment this to cancel the error
}

Application_Error detectará errores de analizador, compilación y tiempo de ejecución en las páginas. No detectará problemas de configuración ni detectará errores que se producen en inetinfo mientras aspnet_isapi procesa la solicitud. Además, al usar la suplantación, el token suplantado debe tener permiso para escribir en este origen de eventos. Puede evitar el problema con la suplantación registrando errores en una base de datos de SQL Server.

Por último, pero no menos importante, las herramientas de depuración de Microsoft® para Windows son muy útiles para depurar problemas en un servidor web de producción. Estas herramientas se pueden descargar desde https://www.microsoft.com/whdc/ddk/debugging/installx86.mspx. Hay una extensión del depurador denominada sos.dll que puede cargar en el depurador windbg.exe o cdb.exe para depurar código administrado. Puede volcar el contenido del montón de recolección de elementos no utilizados (GC), mostrar seguimientos de pila administradas, ayudar a investigar la contención de bloqueos administrados, mostrar estadísticas del grupo de subprocesos y mucho más. Esto se puede descargar como parte del conjunto de herramientas de depuración mencionado en Depuración de producción para aplicaciones de .NET Framework.

Descripción de los contadores de rendimiento

A continuación se muestra una breve descripción de los contadores de rendimiento importantes y cómo usarlos.

Contador de excepciones de .NET CLR

La instancia de contador _Global_ no se debe usar con este contador, ya que todos los procesos administrados lo actualizan. En su lugar, use la instancia de aspnet_wp.

#Exceps se produce por segundo. Número total de excepciones administradas producidas por segundo. A medida que aumenta este número, el rendimiento se degrada. Las excepciones no deben iniciarse como parte del procesamiento normal. Sin embargo, tenga en cuenta que Response.Redirect, Server.Transfer y Response.End hacen que threadAbortException se inicie varias veces, y un sitio que se basa en gran medida en estos métodos incurrirá en una penalización de rendimiento. Si debe usar Response.Redirect, llame a Response.Redirect(url, false), que no llama a Response.End y, por tanto, no se inicia. El inconveniente es que se ejecutará el código de usuario que sigue la llamada a Response.Redirect(url, false). También es posible usar una página HTML estática para redirigir. El artículo de Microsoft Knowledge Base 312629 proporciona más detalles.

Además de supervisar este contador de rendimiento muy útil, se debe usar el evento Application_Error para alertar a los administradores de problemas.

Umbral: 5% de RPS. Los valores mayores que se deben investigar y se debe establecer un nuevo umbral según sea necesario.

Contadores de carga de .NET CLR

La instancia de contador _Global_ no debe usarse con estos contadores de rendimiento, ya que todos los procesos administrados lo actualizan. En su lugar, use la instancia de aspnet_wp.

AppDomains actual. Número actual de AppDomains cargados en el proceso. El valor de este contador debe ser el mismo que el número de aplicaciones web más 1. El appDomain adicional es el dominio predeterminado.
Ensamblados actuales. Número actual de ensamblados cargados en el proceso. De forma predeterminada, los archivos ASPX y ASCX de un directorio están compilados por lotes. Normalmente, esto produce uno a tres ensamblados, en función de las dependencias. Por ejemplo, si hay páginas ASPX con dependencias en tiempo de análisis en archivos ASCX, normalmente se generarán dos ensamblados. Uno contendrá los archivos ASPX, los demás archivos ASCX. Las dependencias en tiempo de análisis incluyen las creadas por las <directivas %@ import %>, <%@ reference %>y <%@ register %> . Un control cargado a través del método LoadControl no crea una dependencia en tiempo de análisis. Tenga en cuenta que global.asax se compila en un ensamblado por sí mismo.

En ocasiones, el consumo excesivo de memoria se debe a un número inusualmente grande de ensamblados cargados. Por ejemplo, un sitio que muestra artículos de noticias funcionará mejor con un pequeño conjunto de archivos ASPX que obtienen las noticias de una base de datos de la que se usaría para cada artículo. Los diseñadores de sitios deben intentar generar contenido dinámicamente, usar el almacenamiento en caché y reducir el número de páginas ASPX y ASCX.

Los ensamblados no se pueden descargar desde un AppDomain. Para evitar un consumo excesivo de memoria, appDomain se descarga cuando el número de recompilaciones (ASPX, ASCX, ASAX) supera el límite especificado por <la compilación numRecompilesBeforeAppRestart=/>. Tenga en cuenta que si el <atributo debug=%> de la página %@ está establecido en true, o si <la compilación debug=/> está establecida en true, la compilación por lotes está deshabilitada.
Bytes en montón del cargador. Número de bytes confirmados por el cargador de clases en todos los appDomains. Este contador debe alcanzar un estado estable. Si este contador aumenta continuamente, supervise el contador "Ensamblados actuales". Puede haber demasiados ensamblados cargados por AppDomain.

Contadores de memoria de .NET CLR

La instancia de contador _Global_ no debe usarse con estos contadores de rendimiento, ya que todos los procesos administrados lo actualizan. En su lugar, use la instancia de aspnet_wp.

# Bytes en todos los montones. Número de bytes confirmados por objetos administrados. Esta es la suma del montón de objetos grandes y los montones de generación 0, 1 y 2. Estas regiones de memoria son de tipo MEM_COMMIT (consulte la documentación del SDK de plataforma para VirtualAlloc). El valor de este contador siempre será menor que el valor de Process\Private Bytes, que cuenta todas las regiones de MEM_COMMIT para el proceso. Bytes privados menos # Bytes en todos los montones es el número de bytes confirmados por objetos no administrados. El primer paso de la investigación del uso excesivo de memoria es determinar si se usa en objetos administrados o no administrados.

Para investigar el uso excesivo de memoria administrada, recomiendo WINDBG.EXE y SOS.DLL, que puede leer sobre en Depuración de producción para aplicaciones de .NET Framework. SOS.DLL tiene un comando "!dumpheap –stat" que enumera el recuento, el tamaño y el tipo de objetos del montón administrado. Puede usar "!dumpheap –mt" para obtener la dirección de un objeto y "!gcroot" para ver sus raíces. El comando "!eeheap" presenta estadísticas de uso de memoria para los montones administrados.

Otra herramienta útil para diagnosticar el uso de memoria es CLR Profiler, que se describe con más detalle a continuación.

Por lo general, la utilización excesiva de memoria administrada se produce por:
1. Leer conjuntos de datos de gran tamaño en la memoria.
2. Crear demasiadas entradas de la caché.
3. Cargar o descargar archivos de gran tamaño.
4. Usar en forma excesiva expresiones regulares o cadenas durante el análisis de archivos.
5. ViewState excesivo.
6. Demasiados datos en estado de sesión o demasiadas sesiones.
# Colecciones gen 0. Número de veces que se han recopilado objetos de generación 0. Los objetos que sobreviven se promueven a la generación 1. Una colección se realiza cuando se necesita espacio para asignar un objeto o cuando alguien fuerza una colección llamando a System.GC.Collect. Las colecciones que implican generaciones más altas tardan más, ya que van precedidas por colecciones de generaciones inferiores. Intente minimizar el porcentaje de colecciones de generación 2. Como regla general, el número de colecciones de generación 0 debe ser 10 veces mayor que el número de colecciones de generación 1 y de forma similar para la generación 1 y 2. Los contadores # Gen N Collections y % Time in GC counter son los mejores para identificar problemas de rendimiento causados por asignaciones excesivas. Consulte la descripción del porcentaje de tiempo en GC para conocer los pasos que puede seguir para mejorar el rendimiento.
# Colecciones gen 1. Número de veces que se han recolectado objetos de generación 1. Los objetos que sobreviven se promueven a la generación 2.

Umbral: una décima parte del valor de #Gen 0 Collections. Las aplicaciones que funcionan bien siguen la regla general mencionada en la descripción del contador #Gen 0 Collections.
# Colecciones gen 2. Número de veces que se han recopilado elementos no utilizados de generación 2. La generación 2 es la más alta, por lo que los objetos que sobreviven a la colección permanecen en la generación 2. Las colecciones gen 2 pueden ser muy costosas, especialmente si el tamaño del montón gen 2 es excesivo.

Umbral: un décimo el valor de #Gen 1 Collections. Las aplicaciones que funcionan bien siguen la regla general mencionada en la descripción del contador #Gen 0 Collections.
% de tiempo de la GC. Porcentaje de tiempo dedicado a realizar la última recolección de elementos no utilizados. Un valor promedio del 5 % o menos se consideraría correcto, pero los picos mayores que esto no son raros. Tenga en cuenta que todos los subprocesos se suspenden durante una recolección de elementos no utilizados.

La causa más común de un porcentaje elevado de tiempo en GC es realizar demasiadas asignaciones por solicitud. La segunda causa más común es insertar una gran cantidad de datos en la memoria caché de ASP.NET, quitarlos, regenerarlos y volver a insertarlos en la memoria caché cada pocos minutos. A menudo hay pequeños cambios que se pueden realizar para reducir considerablemente las asignaciones. Por ejemplo, la concatenación de cadenas puede ser costosa por solicitud, ya que las cadenas concatenadas deben recopilarse como elementos no utilizados. StringBuilder, con una capacidad inicial adecuada, funciona mejor que la concatenación de cadenas. Sin embargo, StringBuilder también debe ser recolección de elementos no utilizados y, si se usa incorrectamente, puede dar lugar a más asignaciones de las esperadas a medida que se cambia el tamaño de los búferes internos. Llamar a Response.Write varias veces en cada cadena funciona incluso mejor que combinarlas con StringBuilder, por lo que si puede evitar StringBuilder altogther, por favor.

Las aplicaciones suelen almacenar datos temporalmente en stringBuilder o MemoryStream al generar una respuesta. En lugar de volver a crear este almacenamiento temporal en cada solicitud, considere la posibilidad de eliminar un grupo de búferes reutilizable de matrices de caracteres o bytes. Un grupo de búferes es un objeto con una rutina GetBuffer y ReturnBuffer . La rutina GetBuffer intenta devolver un búfer desde un almacén interno de búferes, pero crea un nuevo búfer si el almacén está vacío. La rutina ReturnBuffer devuelve el búfer al almacén si aún no se ha alcanzado el número máximo de búferes almacenados, pero lo libera. El inconveniente de esta implementación del grupo de búferes es que requiere bloqueo para la seguridad de subprocesos. Como alternativa, puede evitar el impacto en el rendimiento del bloqueo mediante HttpContext.ApplicationInstance para acceder a un campo de instancia definido en global.asax. Hay una instancia de global.asax para cada instancia de canalización y, por tanto, el campo solo es accesible desde una solicitud cada vez, lo que hace que sea un excelente lugar para almacenar un carácter reutilizable o un búfer de bytes.

Para reducir % de tiempo en GC, debe conocer el patrón de asignación. Use CLR Profiler para generar perfiles de una sola solicitud o un esfuerzo ligero durante un par de minutos como máximo. (Estas herramientas son invasivas y no están pensadas para utilizarse en producton). La vista Gráfico de asignación muestra la memoria total asignada para cada tipo de objeto y la pila de llamadas que realizó la asignación. Úselo para reducir las asignaciones excesivas. La vista Histograma por tamaño (seleccione Tipos asignados de histograma en el menú Ver) resume el tamaño de los objetos asignados. Evite asignar objetos de corta duración de más de 85 000 bytes. Estos objetos se asignan en el montón de objetos grandes y son más caros de recopilar. En la vista Histograma por tamaño, puede seleccionar objetos con el mouse y hacer clic con el botón derecho para ver quién los asignó. Reducir las asignaciones es un proceso iterativo de modificaciones de código y generación de perfiles.

Umbral: un promedio de 5 % o menos; picos de corta duración mayores que estos son comunes. Los valores promedio mayores que se deben investigar. Se debe establecer un nuevo umbral según sea necesario.

contadores de ASP.NET

Los contadores de rendimiento de esta categoría solo se restablecen a 0 cuando se inicia el servicio w3svc.

Reinicios de la aplicación. Número de reinicios de la aplicación. Volver a crear el dominio de la aplicación y volver a compilar páginas tarda tiempo, por lo que se deben investigar los reinicios imprevistos de la aplicación. El dominio de aplicación se descarga cuando se produce una de las siguientes acciones:
- Modificación de machine.config, web.configo global.asax.
- Modificación del directorio bin de la aplicación o de su contenido.
- Cuando el número de compilaciones (ASPX, ASCX o ASAX) supera el límite especificado por <la compilación numRecompilesBeforeAppRestart=/>.
- Modificación de la ruta de acceso física de un directorio virtual.
- Modificación de la directiva de seguridad de acceso a código.
- Se reinicia el servicio web.
En el caso de las granjas de servidores web en producción, se recomienda quitar un servidor de rotación antes de actualizar el contenido para mejorar el rendimiento y la confiabilidad. Para un único servidor web en producción, el contenido se puede actualizar mientras el servidor está bajo carga. La revisión descrita en el artículo de Knowledge Base 810281 es de interés para cualquier persona que experimente errores después de que se reinicie una aplicación, como las infracciones de uso compartido con un error similar a "No se puede acceder a fileName <> porque otro proceso lo está usando".

Se ha corregido un problema relacionado con los reinicios de aplicaciones y software antivirus en el artículo de Knowledge Base 820746: FIX: Algunos programas antivirus pueden hacer que las aplicaciones web se reinicien inesperadamente para la versión 1.0 y en el artículo de Knowledge Base 821438 para la versión 1.1.

Umbral: 0. En un mundo perfecto, el dominio de aplicación sobrevivirá durante la vida del proceso. Se deben investigar valores excesivos y se debe establecer un nuevo umbral según sea necesario.
Aplicaciones en ejecución. Número de aplicaciones que se ejecutan.
Solicitudes actuales. Número de solicitudes controladas actualmente por el ISAPI de ASP.NET. Esto incluye los que están en cola, en ejecución o esperando que se escriban en el cliente. Este contador de rendimiento se agregó a la versión 1.0 de ASP.NET en la revisión anterior a SP3 descrita en el artículo de Knowledge Base 329959.

ASP.NET comenzará a rechazar solicitudes cuando este contador supere la requestQueueLimit definida en la sección de configuración processModel . Tenga en cuenta que requestQueueLimit se aplica a ASP.NET en IIS 5.0 cuando se ejecuta en aspnet_wp, pero quizás sorprendentemente, también se aplica en IIS 6.0 cuando se ejecuta en w3wp. No se sabe que se siguen aplicando varias opciones de configuración processModel al ejecutarse en IIS 6.0. Entre ellos se incluyen requestQueueLimit, responseDeadlockInterval, maxWorkerThreads, maxIoThreads, minWorkerThreads y minIoThreads. Un error en la versión 1.1 de Framework, corregido en ASP.NET paquete acumulativo de revisiones 1.1 de junio de 2003, permitía ASP.NET controlar un número infinito de solicitudes al ejecutarse en IIS 6.0. La corrección hace que ASP.NET rechazar solicitudes cuando Requests Current supere requestQueueLimit.

En el caso de las aplicaciones ASP clásicas, Las solicitudes en cola proporcionan una advertencia para cuándo se rechazarán las solicitudes. Para ASP.NET, Requests Current, junto con Las solicitudes en la cola de aplicaciones, proporcionan esta funcionalidad. Este contador también lo usa el mecanismo de detección de interbloqueos ASP.NET. Si Requests Current es mayor que 0 y no se han recibido respuestas del proceso de trabajo durante un tiempo mayor que el límite especificado por <processModel responseDeadlockInterval=/>, se finaliza el proceso y se inicia un nuevo proceso. En la revisión anterior a SP3 descrita en el artículo de Knowledge Base 328267, el algoritmo se modificó para que Requests Current debe ser mayor que la suma de maxWorkerThreads más maxIoThreads, especificada en la < sección processModel/>configuration. Tenga en cuenta que, de forma predeterminada, el tiempo de espera de ejecución de la solicitud es de 90 segundos y es intencionadamente menor que responseDeadlockInterval. El tiempo de espera de ejecución de la solicitud se puede modificar a través del < valor de configuración httpRuntime executionTimeout=/> o la propiedad Server.ScriptTimeout, pero siempre debe ser menor que responseDeadlockInterval.
Tiempo de ejecución de la solicitud. Número de milisegundos que se toman para ejecutar la última solicitud. En la versión 1.0 de Framework, el tiempo de ejecución comienza cuando el proceso de trabajo recibe la solicitud y se detiene cuando la ISAPI de ASP.NET envía HSE_REQ_DONE_WITH_SESSION a IIS. Para la versión 5 de IIS, esto incluye el tiempo necesario para escribir la respuesta en el cliente, pero para la versión 6 de IIS, los búferes de respuesta se envían de forma asincrónica y, por lo tanto, no se incluye el tiempo necesario para escribir la respuesta en el cliente. Por lo tanto, en la versión 5 de IIS, un cliente con una conexión de red lenta aumentará considerablemente el valor de este contador.

En la versión 1.1 de Framework, el tiempo de ejecución comienza cuando se crea HttpContext para la solicitud y se detiene antes de enviar la respuesta a IIS. Suponiendo que el código de usuario no llama a HttpResponse.Flush, esto implica que el tiempo de ejecución se detiene antes de enviar bytes a IIS o al cliente por ese motivo.

ASP.NET\Tiempo de ejecución de solicitudes es un contador de instancia y muy volátil. Por otro lado, el tiempo para el último byte (TTLB) se puede calcular fácilmente y usar para calcular una mejor estimación del rendimiento durante un período de tiempo. TTLB se puede calcular a través de un cliente HTTP simple escrito en código administrado, o bien puede usar uno de los muchos clientes HTTP disponibles que calculan TTLB, como Application Center Test (ACT).

Tenga en cuenta que si <la compilación debug=/> está establecida en TRUE, se deshabilitará la compilación por lotes y se omitirá la < configuración httpRuntime executionTimeout=/>, así como las llamadas a Server.ScriptTimeout. Esto puede causar problemas si la < configuración responseDeadlockInterval=/> de processModel no está establecida en Infinite, ya que las solicitudes de páginas de depuración se pueden ejecutar teóricamente para siempre.

Umbral: N.A. El valor de este contador debe ser estable. La experiencia le ayudará a establecer un umbral para un sitio determinado. Cuando el modelo de proceso está habilitado, el tiempo de ejecución de la solicitud incluye el tiempo necesario para escribir la respuesta al cliente y, por tanto, depende del ancho de banda de la conexión del cliente.
Solicitudes en cola. Número de solicitudes actualmente en cola. Cuando se ejecuta en IIS 5.0, hay una cola entre inetinfo y aspnet_wp, y hay una cola para cada directorio virtual. Cuando se ejecuta en IIS 6.0, hay una cola donde las solicitudes se publican en threadPool administrado desde código nativo y una cola para cada directorio virtual. Este contador incluye solicitudes en todas las colas. La cola entre inetinfo y aspnet_wp es una canalización con nombre a través de la que la solicitud se envía de un proceso a otro. El número de solicitudes de esta cola aumenta si hay una escasez de subprocesos de E/S disponibles en el proceso de aspnet_wp. En IIS 6.0 aumenta cuando hay solicitudes entrantes y una escasez de subprocesos de trabajo.

Tenga en cuenta que las solicitudes se rechazan cuando el contador Requests Current supera el <processModel requestQueueLimit=/>. Muchas personas piensan que esto ocurre cuando el contador Requests Queued supera requestQueueLimit, pero esto no es el caso. Cuando se supera este límite, las solicitudes se rechazarán con un código de estado 503 y el mensaje "El servidor está demasiado ocupado". Si se rechaza una solicitud por este motivo, nunca llegará al código administrado y no se notificará a los controladores de errores. Normalmente, esto solo es un problema cuando el servidor está bajo una carga muy pesada, aunque una carga de "ráfaga" cada hora también podría provocar esto. Para el escenario de carga de ráfaga inusual, es posible que le interese la revisión descrita en el artículo de Knowledge Base 810259, lo que le permitirá aumentar el número mínimo de subprocesos de E/S del valor predeterminado de 1 por CPU.

Cada directorio virtual tiene una cola que usa para mantener la disponibilidad de los subprocesos de trabajo y E/S. El número de solicitudes de esta cola aumenta si el número de subprocesos de trabajo disponibles o subprocesos de E/S disponibles está por debajo del límite especificado por <httpRuntime minFreeThreads=/>. Cuando se supera el límite especificado por <httpRuntime appRequestQueueLimit=/> , la solicitud se rechaza con un código de estado 503 y el cliente recibe una httpException con el mensaje "Servidor demasiado ocupado".

Por sí mismo, este contador no es un indicador claro de problemas de rendimiento, ni se puede usar para determinar cuándo se rechazarán las solicitudes. En el artículo de Knowledge Base 329959, se introdujeron dos nuevos contadores de rendimiento para solucionar este problema: Solicitudes actuales y solicitudes en cola de aplicaciones. Consulte las descripciones de estos dos contadores, así como para las solicitudes rechazadas.
Solicitudes rechazadas. Número de solicitudes rechazadas. Las solicitudes se rechazan cuando se supera uno de los límites de la cola (consulte la descripción de las solicitudes en cola). Las solicitudes se pueden rechazar por varias razones. La latencia de back-end, como la causada por un servidor SQL Server lento, suele ir precedida de un aumento repentino del número de instancias de canalización y una disminución en el uso de cpu y solicitudes/s. Un servidor puede sobrecargarse durante los tiempos de carga pesada debido a restricciones de procesador o memoria que, en última instancia, dan lugar al rechazo de las solicitudes.

El diseño de una aplicación puede dar lugar a un tiempo de ejecución excesivo de solicitudes. Por ejemplo, la compilación por lotes es una característica en la que todas las páginas de un directorio se compilan en un único ensamblado cuando se recibe la primera solicitud de una página. Si hay varios cientos de páginas en un directorio, la primera solicitud en este directorio puede tardar mucho tiempo en ejecutarse. Si < se supera la compilación batchTimeout=/> , la compilación por lotes continuará en un subproceso en segundo plano y la página solicitada se compilará individualmente. Si la compilación por lotes se realiza correctamente, el ensamblado se conservará en el disco y se puede reutilizar después de reiniciar la aplicación. Sin embargo, si se modifica global.asax, web.config, machine.config o un ensamblado en la carpeta bin de la aplicación, el proceso de compilación por lotes se ejecutará de nuevo debido al cambio de dependencia.

Un diseño cuidadoso de un sitio grande puede tener un impacto significativo en el rendimiento. En este caso, es mejor tener solo algunas páginas que varían el comportamiento en función de los datos de cadena de consulta. En general, debe minimizar el tiempo de ejecución de la solicitud, que se supervisa mejor mediante el promedio de tiempo para el último byte (TTLB) mediante un cliente HTTP que solicita una o varias páginas del sitio web.

Los siguientes contadores de rendimiento son más adecuados para detectar la causa de las solicitudes rechazadas:
- Proceso\% tiempo de procesador
- Proceso\Bytes privados
- Proceso\Recuento de subprocesos
- Solicitudes de extensión de ISAPI\Servicio web/s
- ASP.NET\Requests Current
- ASP.NET\Requests Queued
- ASP.NET\Tiempo de espera de solicitud
- ASP.NET Applications\Pipeline Instance Count
- ASP.NET Aplicaciones\Solicitudes en la cola de aplicaciones
Umbral: 0. El valor de este contador debe ser 0. Los valores mayores que se deben investigar.
Tiempo de espera de solicitud. Número de milisegundos que la solicitud más reciente pasó esperando en la cola, o canalización con nombre, que existe entre inetinfo y aspnet_wp (consulte la descripción de las solicitudes en cola). Esto no incluye ningún tiempo dedicado a esperar en las colas de la aplicación.

Umbral: 1000. La solicitud promedio debe gastar 0 milisegundos en espera en la cola.
Procesos de trabajo en ejecución. Número actual de procesos de trabajo de aspnet_wp. Durante un breve período de tiempo, un nuevo proceso de trabajo y el proceso de trabajo que se va a reemplazar pueden coexistir. Aunque es poco frecuente, a veces procesa el interbloqueo mientras salen. Si sospecha esto, considere la posibilidad de usar una herramienta para supervisar el número de instancias del proceso de trabajo. Como alternativa, se puede usar el contador de rendimiento Memoria\Mbytes disponibles, ya que estos procesos pendientes consumirán memoria.

Umbral: 2. Durante el apagado del proceso de trabajo anterior, puede haber dos instancias. Si webGarden está habilitado, el umbral debe ser #CPUs más 1. Los valores mayores que esto pueden indicar reinicios excesivos del proceso en un período de tiempo muy corto.
Reinicios del proceso de trabajo. Número de reinicios del proceso de aspnet_wp.

Umbral: 1. Los reinicios del proceso son costosos y no deseados. Los valores dependen de las opciones de configuración del modelo de proceso, así como de infracciones de acceso imprevistas, fugas de memoria y interbloqueos. Si aspnet_wp reinicia, una entrada registro de eventos de aplicación indicará por qué. Las solicitudes se perderán si se produce una infracción de acceso o un interbloqueo. Si la configuración del modelo de proceso se usa para reciclar previamente el proceso, será necesario establecer un umbral adecuado.

Contadores de aplicaciones de ASP.NET

Los contadores de rendimiento de esta categoría se restablecen a 0 cuando se reinicia el dominio de aplicación o el servicio web.

Total de entradas de caché. Número actual de entradas en la memoria caché (usuario e interno). Internamente, ASP.NET usa la memoria caché para almacenar objetos que son costosos de crear, incluidos objetos de configuración, entradas de ensamblado conservadas, rutas de acceso asignadas por el método MapPath y objetos de estado de sesión en proceso.

Nota La familia "Total de caché" de contadores de rendimiento es útil para diagnosticar problemas con el estado de sesión en proceso. El almacenamiento de demasiados objetos en la memoria caché suele ser la causa de pérdidas de memoria.
Proporción total de aciertos de caché. La proporción total de llamadas a errores de todas las solicitudes de caché (tanto de usuario como interna).
Tasa de rotación total de caché. Número de adiciones y eliminaciones en la memoria caché por segundo (tanto el usuario como el interno). Una tasa de rotación alta indica que los artículos se agregan y quitan rápidamente, lo que puede ser costoso.
Entradas de API de caché. Número de entradas que se encuentran actualmente en la memoria caché del usuario.
Proporción de aciertos de API de caché. La proporción total de llamadas a errores de las solicitudes de caché de usuarios.
Tasa de rotación de API de caché. Número de adiciones y eliminaciones en la memoria caché del usuario por segundo. Una tasa de rotación alta indica que los artículos se agregan y quitan rápidamente, lo que puede ser costoso.
Entradas de caché de salida. Número de entradas actualmente en la caché de resultados.
Proporción de aciertos de caché de salida. Proporción total de llamadas a errores de las solicitudes de caché de salida.
Tasa de rotación de caché de salida. Número de adiciones y eliminaciones en la memoria caché de salida por segundo. Una tasa de rotación alta indica que los artículos se agregan y quitan rápidamente, lo que puede ser costoso.
Recuento de instancias de canalización. Número de instancias de canalización activas. Solo se puede ejecutar un subproceso de ejecución dentro de una instancia de canalización, por lo que este número proporciona el número máximo de solicitudes simultáneas que se procesan para una aplicación determinada. El número de instancias de canalización debe ser estable. Los aumentos repentinos son indicativos de la latencia de back-end (consulte la descripción de las solicitudes rechazadas anteriormente).
Total de compilaciones. Número de archivos ASAX, ASCX, ASHX, ASPX o ASMX que se han compilado. Este es el número de archivos compilados, no el número de ensamblados generados. Los ensamblados se conservan en el disco y se reutilizan hasta la hora de creación, la hora de última escritura o la duración de los cambios de dependencia de archivo. Las dependencias de una página ASPX incluyen global.asax, web.config, machine.config, ensamblados dependientes en la carpeta bin y archivos ASCX a los que hace referencia la página. Si reinicia la aplicación sin modificar ninguna de las dependencias de archivo, el ensamblado conservado se volverá a cargar sin necesidad de ninguna compilación. Este contador de rendimiento solo aumentará cuando un archivo se analice inicialmente y se compile en un ensamblado.

De forma predeterminada, la compilación por lotes está habilitada, sin embargo, este contador aumentará una vez para cada archivo que se analiza y compila en un ensamblado, independientemente del número de ensamblados creados.

Si se produce un error en la compilación, el contador no se incrementará.
Errores durante el preprocesamiento. Número total de errores de configuración y análisis. Este contador se incrementa cada vez que se produce un error de configuración o un error de análisis. Aunque los errores de configuración se almacenan en caché, el contador aumenta cada vez que se produce el error.

Nota No confíe únicamente en los contadores de rendimiento "Errores" para determinar si el servidor está en buen estado. Se restablecen en cero cuando se descarga appDomain. Sin embargo, se pueden usar para profundizar en un problema específico. En general, use el evento Application_Error para alertar a los administradores de problemas.
Errores durante la compilación. Número total de errores de compilación. La respuesta se almacena en caché y este contador se incrementa una sola vez hasta que un cambio de archivo fuerza la recompilación. Implemente el control de errores personalizado para generar un evento.
Errores durante la ejecución. Número total de errores en tiempo de ejecución.
Errores no controlados durante la ejecución. Número total de excepciones no controladas en tiempo de ejecución. Esto no incluye lo siguiente:
1. Errores borrados por un controlador de eventos (por ejemplo, por Page_Error o Application_Error).
2. Errores administrados por una página de redireccionamiento.
3. Errores que se producen dentro de un bloque try/catch.
Errores no controlado durante la ejecución/s. Número total de excepciones no controladas por segundo en tiempo de ejecución.
Total de errores. Suma de errores durante el preprocesamiento, errores durante la compilación y errores durante la ejecución.
Errores totales/s. El total de errores durante el preprocesamiento, los errores durante la compilación y los errores durante la ejecución por segundo.
Solicitudes en ejecución. Número de solicitudes que se están ejecutando actualmente. Este contador se incrementa cuando HttpRuntime comienza a procesar la solicitud y se disminuye después de que HttpRuntime finalice la solicitud. En la versión 1.1 de Framework, hay un error en este contador de rendimiento que se corrige en el paquete acumulativo de revisiones de ASP.NET 1.1 de junio de 2003. Desafortunadamente, el error no se describe en el artículo de Knowledge Base. Antes de la corrección, el contador incluía el tiempo necesario para escribir la respuesta al cliente.
Solicitudes en la cola de aplicaciones. El número de solicitudes de la cola de solicitudes de aplicación (consulte la descripción de las solicitudes en cola anteriormente). Además de Las solicitudes actuales, las solicitudes en la cola de aplicaciones proporcionan una advertencia para cuándo se rechazarán las solicitudes. Si solo hay un par de directorios virtuales, puede ser adecuado aumentar el valor predeterminado appRequestQueueLimit a 200 o 300, especialmente para aplicaciones lentas con mucha carga.
Solicitudes no encontradas. Número de solicitudes de recursos no encontrados.
Solicitudes no autorizadas. Error en el número de solicitudes debido al acceso no autorizado.
Se agota el tiempo de espera de las solicitudes. Número de solicitudes que han agotado el tiempo de espera.
Solicitudes correctas. Número de solicitudes que se han ejecutado correctamente.
Total de solicitudes. Número de solicitudes desde que se inició la aplicación.
Solicitudes por segundo. Número de solicitudes ejecutadas por segundo. Prefiero "Solicitudes de extensión de ISAPI\servicio web/s" porque no se ve afectado por los reinicios de la aplicación.

Contadores de procesos

Con estos contadores, los procesos de interés son aspnet_wp e inetinfo.

% de tiempo de procesador. Porcentaje de tiempo que los subprocesos de este proceso pasan usando los procesadores.

Umbral: 70%. Los valores mayores que esto durante largos períodos de tiempo indican la necesidad de comprar hardware o optimizar la aplicación.
Recuento de identificadores.

Umbral: 10000. Un recuento de identificadores de 2000 en aspnet_wp es sospechoso y 10 000 está mucho más allá de los límites aceptables. Se producirá una degradación notable del rendimiento si el número total de identificadores de todos los procesos supera aproximadamente 40 000, lo que es totalmente factible durante un ataque por denegación de servicio contra IIS.
Bytes privados. Tamaño actual, en bytes, de la memoria confirmada propiedad de este proceso. Las fugas de memoria se identifican mediante un aumento coherente y prolongado en bytes privados. Este es el mejor contador de rendimiento para detectar fugas de memoria.

Cuando se ejecuta en IIS 5.0, se debe establecer un límite de memoria para bytes privados en la <sección processModel memoryLimit=/ configuration (Configuración de processModel memoryLimit=/> ). Cuando se ejecuta en IIS 6.0, el límite de memoria debe establecerse en el Administrador de IIS. Abra Propiedades para el grupo de aplicaciones y, en la pestaña Reciclaje, especifique un límite para Memoria máxima usada (en megabytes). Este límite corresponde a Bytes privados. Los bytes privados para el proceso de trabajo se comparan con el límite de memoria para determinar cuándo se debe reciclar el proceso. System.Web.Caching.Cache también usa bytes privados y el límite de memoria para determinar cuándo eliminar elementos de la memoria caché y, por tanto, evitar el reciclaje del proceso. Se recomienda un límite de memoria del 60 % de la RAM física para evitar la paginación, especialmente cuando un nuevo proceso reemplaza al antiguo debido al consumo excesivo de memoria. Tenga en cuenta que el artículo de Knowledge Base 330469 resuelve un problema con ASP.NET en el que no puede supervisar bytes privados en servidores con un gran número de procesos en ejecución. Esta revisión también permite que el administrador de memoria caché funcione correctamente cuando hay un gran número de procesos en ejecución.

Es importante ajustar el límite de memoria en las máquinas con grandes cantidades de RAM física, de modo que el administrador de memoria caché y el reciclaje de procesos funcionen correctamente. Por ejemplo, supongamos que tiene un servidor con 4 gigabytes (GB) de RAM física que usa el límite de memoria predeterminado. Esto es un problema. El sesenta por ciento de la RAM física es de 2,4 GB, que es mayor que el espacio de direcciones virtuales predeterminado de 2 GB. ¿En qué debe establecerse el límite de memoria?

Hay un par de cosas que hay que tener en cuenta: En primer lugar, la probabilidad de experimentar una excepción OutOfMemoryException comienza a aumentar drásticamente cuando "Process\Virtual Bytes" está dentro de 600 MB del límite de espacio de direcciones virtual (generalmente 2 GB) y, en segundo lugar, las pruebas han demostrado que "Process\Virtual Bytes" suele ser mayor que "Process\Private Bytes" en no más de 600 MB. Esta diferencia se debe en parte a las regiones MEM_RESERVE mantenidas por el GC, lo que le permite confirmar rápidamente más memoria cuando sea necesario. Esto implica que cuando "Process\Private Bytes" supera los 800 MB, aumenta la probabilidad de experimentar una excepción OutOfMemoryException . En este ejemplo, la máquina tiene 4 GB de RAM física, por lo que debe establecer el límite de memoria en el 20 % para evitar condiciones de memoria insuficiente. Puede experimentar con estos números para maximizar el uso de memoria en una máquina, pero si desea reproducirlo seguro, los números del ejemplo funcionarán.

En resumen, establezca el límite de memoria en el menor del 60 % de la RAM física o 800 MB. Dado que v1.1 admite 3 GB de espacio de direcciones virtuales, si agrega /3 GB a boot.ini, puede usar de forma segura 1800 MB en lugar de 800 MB como límite superior.

Tenga en cuenta que, al ejecutar pruebas, si desea forzar una gc y estabilizar la memoria administrada, puede llamar a System.GC.GetTotalMemory(true) una vez. Este método llamará a GC. Recopilar y WaitForPendingFinalizers() repetidamente hasta que la memoria se estabiliza en un 5 %.

Umbral: el mínimo del 60 % de la RAM física y 800 MB. Los valores mayores que el 60 % de la RAM física total comienzan a afectar al rendimiento, especialmente durante los reinicios de la aplicación y del proceso. La liklihood de outOfMemoryException aumenta considerablemente cuando los bytes privados superan los 800 MB en un proceso con un límite de espacio de direcciones virtual de 2 GB.
Recuento de subprocesos. Número de subprocesos activos en este proceso. El recuento de subprocesos suele aumentar cuando la carga es demasiado alta.

Umbral: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs)). El umbral debe aumentarse si se usa el modo aspcompat: Umbral: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs * 2).
Bytes virtuales. Tamaño actual, en bytes, del espacio de direcciones virtuales para este proceso.

El límite de espacio de direcciones virtuales de un proceso en modo de usuario es de 2 GB, a menos que se habilite 3 GB de espacio de direcciones mediante el modificador /3GB en boot.ini. El rendimiento se degrada a medida que se aproxima este límite y normalmente produce un bloqueo del proceso o del sistema. El espacio de direcciones se fragmenta a medida que se aproxima el límite de 2 GB o 3 GB, por lo que recomiendo un umbral conservador de 1,4 o 2,4 GB, respectivamente. Si tiene problemas aquí, verá que se está iniciando System.OutOfMemoryException y esto puede o no bloquear el proceso.

Cuando se ejecuta en IIS 6.0, se puede establecer un límite de memoria virtual en el Administrador de IIS. Sin embargo, establecer esto incorrectamente puede causar problemas para ASP.NET. ASP.NET eliminar elementos de la memoria caché para evitar superar el límite de bytes privados, pero el algoritmo usa bytes privados y el límite de bytes privados en esta determinación. No supervisa los bytes virtuales ni el límite de bytes virtuales. Dado que la diferencia entre bytes virtuales y bytes privados no suele ser superior a 600 MB, podría establecer el límite de bytes virtuales en un valor de 600 MB mayor que el límite de bytes privados si le preocupa la posibilidad de fugas de memoria virtual o fragmentación. Si esto es deseable, establezca un límite para memoria virtual máxima (en megabytes), que se encuentra en la pestaña Reciclaje para las propiedades del grupo de aplicaciones.

La versión 1.0 de Framework no admite 3 GB de espacio de direcciones en el proceso de trabajo o el servicio de estado. Sin embargo, consulte el artículo de Knowledge Base 320353 para obtener instrucciones para habilitar el espacio de direcciones de 3 GB en inetinfo.exe. La versión 1.1 es totalmente compatible con el espacio de direcciones de 3 GB para el proceso de trabajo y el servicio de estado.

Umbral: 600 MB menos que el tamaño del espacio de direcciones virtuales; ya sea de 1,4 o 2,4 GB.

Contador de procesador

% de tiempo de procesador. Porcentaje de tiempo que todos los subprocesos dedican a usar los procesadores.

Umbral: 70%. Los valores mayores que esto durante largos períodos de tiempo indican la necesidad de comprar hardware o optimizar la aplicación.

Contador de memoria

Mbytes disponibles. Cantidad de RAM física disponible.

Umbral: 20 % de la RAM física. Los valores inferiores a esto se deben investigar y pueden indicar la necesidad de adquirir hardware.

Contador del sistema

Modificadores de contexto por segundo. Velocidad a la que los procesadores cambian los contextos de subprocesos. Un número alto puede indicar una contención de bloqueo alta o transiciones entre el modo de usuario y kernel. Los modificadores de contexto/s deben aumentar linealmente con el rendimiento, la carga y el número de CPU. Si aumenta exponencialmente, hay un problema. Se debe usar un generador de perfiles para una investigación más detallada.

Contadores de servicio web

Conexiones actuales. Un umbral para este contador depende de muchas variables, como el tipo de solicitudes (ISAPI, CGI, HTML estático, etc.), el uso de cpu, etc. Se debe desarrollar un umbral a través de la experiencia.
Total de solicitudes de método/s. Se usa principalmente como métrica para diagnosticar problemas de rendimiento. Puede ser interesante compararlo con "ASP.NET Applications\Requests/sec" y "Web Service\ISAPI Extension Requests/sec" para ver el porcentaje de páginas estáticas atendidas frente a las páginas representadas por aspnet_isapi.dll.
Solicitudes de extensión ISAPI/s. Se usa principalmente como métrica para diagnosticar problemas de rendimiento. Puede ser interesante compararlo con "ASP.NET Applications\Requests/sec" y "Web Service\Total Method Requests/sec". Tenga en cuenta que esto incluye solicitudes a todas las extensiones de ISAPI, no solo aspnet_isapi.dll.

Conclusión

Las pruebas cuidadosas de esfuerzo y rendimiento de una aplicación antes de iniciarse pueden prevenir un dolor de cabeza importante. Parece haber dos grandes bloques de saltos de tamaño que muchas personas encuentran:

Debe usar un cliente HTTP capaz de simular el tráfico y la carga que espera que experimente el sitio web.
Debe probar toda la aplicación en un entorno casi idéntico al entorno de producción.

No es fácil simular el tráfico real del sitio web, pero honestamente puedo decir que la mayoría de las aplicaciones que experimentan problemas nunca se probaron adecuadamente. Este artículo debe ayudarle a comprender los contadores de rendimiento y a crear algunas herramientas útiles para supervisar el rendimiento. Para aplicar la carga, recomiendo Microsoft Application Center Test (ACT), que se incluye con Microsoft® Visual Studio® .NET. Puede obtener más información sobre esta herramienta de esfuerzo en Microsoft Application Center Test 1.0, Visual Studio .NET Edition. También recomiendo Microsoft® Web Application Stress Tool (WAST). Puede descargarse gratuitamente desde TechNet. Si la aplicación usa ViewState, deberá usar ACT, ya que WAST no puede analizar dinámicamente la respuesta.

No sé lo que es sobre los entornos de producción, pero definitivamente hay algo especial sobre ellos. No puedo contar las veces que he oído la declaración: "El problema solo se produce en nuestro sitio de producción". Normalmente, la diferencia es la propia aplicación. A menudo hay alguna parte de la aplicación que no se puede simular en el laboratorio. Por ejemplo, el servidor de anuncios se omitió de las pruebas o la base de datos usada para simular la base de datos real es sustancialmente diferente. A veces, las diferencias de red o DNS son la causa y, a veces, es una diferencia en el hardware en el que se ejecutan los servidores.

He estado depurando y supervisando el rendimiento de las aplicaciones de ASP.NET durante varios años, pero todavía hay momentos en los que necesito ayuda. Si se encuentra en esta posición, los foros del sitio web de ASP.NET son un buen lugar para buscar respuestas. Pero si realmente está en un enlace, no dude en ponerse en contacto con el soporte técnico de Microsoft con la información de contacto proporcionada en ese sitio. Tenga en cuenta que si Microsoft determina que un problema es el resultado de un defecto en un producto de Microsoft, no se le cobrará por ese incidente.

Esperamos que este documento le haya equipado con las herramientas y la información que necesita para garantizar la confiabilidad y el rendimiento de la aplicación. Si tiene alguna pregunta, hágalos en ASP.NET Web y haré todo lo posible para responderlos. Buena suerte.

Acerca del autor

Thomas Marquardt es un desarrollador del equipo de ASP.NET en Microsoft. Ha estado depurando e investigando problemas de rendimiento con ASP.NET aplicaciones desde el invierno de 2000. Thomas desea dar las gracias a Dmitry Robsman, director de desarrollo por ASP.NET en Microsoft, durante horas y horas de ayuda y orientación a lo largo de los años.

Compartir a través de