visual studio plugin net dotmemory asp asp.net performance profiling

asp.net - plugin - visual studio profiler



un misterio de cuello de botella de rendimiento de ASP.NET (7)

¿El host utiliza el Pool de aplicaciones?

¿Intentó aumentar el número a 5 a 10 en

An Application Pool -> Performance -> Web Garden -> Max Number of worker processes

Una aplicación ASP.NET clásica: AppSrv + MS SQL DB. Ambos servidores son pesados ​​8 núcleos, 20 GB de RAM. Cuando se realizan pruebas de carga, el rendimiento llega a 400 VirtualUsers (según LoadRunner), con una CPU que utiliza aproximadamente el 30% de un servidor de bases de datos principalmente en ralentí: los tiempos de respuesta aumentan de forma espectacular, hasta el punto de no responder.

Los sospechosos habituales, como Max Pool que se agota y conn limit en el conjunto de ASP.NET no tienen la culpa: Max Pool está configurado en 200 y se utilizan unas 80 conns; el límite de conn se establece en 0.

Ejecuté con ANTS profiler el código y mostró que el bloqueo de subprocesos no contribuyó significativamente.

Ideas muy bienvenidas!


Agregue el registro a su aplicación con una ID de solicitud única apropiada para que pueda rastrear efectivamente cuánto tarda cada operación dentro de una carga de página. Por ejemplo, el registro antes y después de cada llamada a la base de datos mostrará si las llamadas a la base de datos tardan mucho tiempo o no.

Como otros han sugerido, agregar el registro / perfil en el lado de la base de datos mostrará si está en punto muerto (o similar).


El problema es probablemente en su archivo machine.config .

Debe verificar los siguientes parámetros de configuración:

  • maxconnection
  • maxIoThreads
  • maxWorkerThreads
  • minFreeThreads
  • minLocalRequestFreeThreads

Para una descripción breve, compruebe: IIS 6.0 Tuning for Performance

Hay algunas diferencias entre ASP.NET 1.1 y ASP.NET 2.0

ASP.NET 1.1

Pautas sobre algunos valores prácticos que puede encontrar en:

Los valores predeterminados son bajos para cualquier uso práctico y deben corregirse según las sugerencias en los artículos vinculados.

ASP.NET 2.0

Los parámetros se mueven a la sección processModel y los parámetros se configuran automáticamente. Además de la configuración automática, puede establecer manualmente los valores de los parámetros, por lo que debe verificar si:

  • processModel está habilitado
  • autoConfig está establecido en true
    o
  • los parámetros están configurados para corregir valores

Para una descripción detallada, consulte: ASP.Net 2.0 processModelo



Recientemente, sintonizamos nuestra aplicación web utilizando la siguiente guía de configuración de rendimiento de IIS que resultó ser muy exitosa.

Hubo dos configuraciones específicas del servidor que cambiamos;

Uso de la memoria del conjunto de trabajo : los servidores que ejecutan Windows Server ™ 2003 están configurados de manera predeterminada para dar preferencia al caché del sistema de archivos sobre el conjunto de trabajo cuando se asigna la memoria. Microsoft hace esto porque Windows se beneficia de tener un caché de sistema de archivos grande. Siendo que IIS se coloca encima del sistema operativo Windows, también se beneficia de tener un caché de sistema de archivos grande. Sin embargo, si su servidor es un servidor IIS dedicado, es posible que vea un mejor rendimiento si cambia la prioridad al conjunto de trabajo. La razón detrás de esto es si se da preferencia a la caché del sistema de archivos, el código paginable a menudo se escribe en la memoria virtual. La próxima vez que se necesite esta información, se debe paginar a otra cosa a la memoria virtual y la información previamente paginada se debe leer en la memoria física antes de poder usarla. Esto resulta en un procesamiento muy lento.

Rendimiento de red : de forma predeterminada, los servidores que ejecutan Windows Server 2003 están configurados para dar preferencia al caché del sistema de archivos sobre los conjuntos de procesos activos al asignar memoria (a través de la propiedad del servidor Maximizar el rendimiento de los datos para compartir archivos). Aunque los servidores basados ​​en IIS 6.0 se benefician de una memoria caché de sistema de archivos grande, la preferencia de memoria caché del sistema de archivos a menudo hace que el código pausado de IIS 6.0 se escriba en el disco, lo que da como resultado demoras de procesamiento prolongadas. Para evitar estos retrasos en el procesamiento, configure las propiedades del servidor para maximizar el rendimiento de los datos para las aplicaciones de red.

Los siguientes servicios no son necesarios en un servidor web dedicado:

  • Alerta
  • ClipBook
  • Navegador de computadora
  • Cliente DHCP
  • servidor DHCP
  • Servicio de fax
  • Replicación de archivos
  • Monitor infrarrojo
  • Conexión a Internet compartida
  • Mensajero
  • Uso compartido de escritorio remoto de NetMeeting
  • DDE de red
  • DDE DSDM de red
  • NWLink NetBIOS
  • NWLink IPX / SPX
  • Cola de impresión
  • Servicio TCP / IP NetBIOS Helper
  • Telefonía
  • Telnet
  • Fuente de poder ininterrumpible

También verifique la saturación de la red. Asegúrese de no estar maximizando la conexión de red entre su máquina de prueba de carga y el servidor web. Además, si devuelve una gran cantidad de datos pesados ​​de texto / binarios entre su web y el servidor de la base de datos, supervise esa conexión de red.


Cuando no se manchan las CPU y las páginas tienden a dejar de responder, mi primera corazonada es el bloqueo de la base de datos. Un hilo puede contener el resto cuando no se libera un bloqueo en una tabla, lo que da como resultado páginas que no responden mientras el servidor db está inactivo.

¿Se puede utilizar una herramienta de monitoreo sql para verificar el uso correcto en la máquina de la base de datos y ver si todos los usuarios obtienen sus datos correctamente?

Otra cosa; ¿Qué información puedes dar sobre el uso de la memoria?