Determinar qué ejerce presión sobre IIS

Question

Tengo un servidor dedicado que ejecuta tanto IIS 7.5 como SQL Server 2010. La carga de la CPU del servidor suele ser cercana al 100%. El servidor SQL no requiere demasiado, pero el proceso w3wp requiere una gran cantidad de CPU (a menudo más del 70%).

me gustaría saber, lo que está causando esta presión: * Demasiadas solicitudes de archivos estáticos (un CDN se podría añadir) * Demasiados peticiones Ajax (pienso en los zócalos del cometa/web de todos modos) * Páginas asp.net simples que consumen demasiada potencia de procesamiento (debe ser fácil de optimizar)

¿Dónde comenzaría buscando información sobre dónde empezar a optimizar?

Answer 1

La manera más fácil es perfilar la aplicación en producción. No estoy seguro si eso es posible en su caso. Algunas opciones:

• mira en los registros y mira la duración de las solicitudes. Es probable que las solicitudes largas pongan carga en el sistema
• Depuración remota w3wp con Visual Studio y pausa el depurador 10 veces para ver dónde se detiene más. Esa es la zona activa
• Use XPerf o PerfView para capturar pilas (administradas). Esto casi no tiene impacto en el rendimiento de producción

Answer 2

Probablemente la manera más fácil de resolverlo sería instalar New Relic en el servidor. La prueba dura 30 días, creo, así que debería darte suficiente tiempo para llegar al fondo de esto. Le mostrará consultas SQL de larga ejecución, métodos .NET, así como casi todo lo demás que pueda pensar. Hace que sea muy fácil identificar los cuellos de botella.

---

Por cierto, sugerí New Relic porque parece que su problema está en un entorno de producción. New Relic no es un perfilador increíblemente detallado. Recopila suficiente información para ser útil, pero no tanto como para ralentizar el servidor. Eso lo hace muy adecuado para este propósito.

Si, sin embargo, puede reproducir el problema en un entorno de desarrollo, puede intentar algo como el Eqatec profiler gratuito.

Answer 3

Un buen punto de partida sería encender las herramientas de desarrollo (F12 en IE/Chrome) y observar los tiempos en la pestaña de red. Esto le mostrará un diagrama de estilo cascada sobre cómo se cargó la página y le ayudará a identificar cualquier archivo estático que se cargue lentamente y que se pueda mover sensiblemente a un cdn, se realizarán solicitudes innecesarias, cuánto tiempo se estará invirtiendo la página real en sí, etc.

Después de eso, perfile la aplicación con un perfilador de rendimiento. Un buen generador de perfiles como ANTS Performance Profiler le permitirá ver cosas como el tiempo de ejecución/recuentos de aciertos para diferentes métodos, así como también las consultas de base de datos que se están ejecutando y el tiempo que llevan. Una nueva versión de ANTS (actualmente en EAP) también agrupará esa actividad por solicitud http para que pueda ver si las páginas específicas necesitan optimización o si las golpean demasiadas veces.

También debería asegurarse de que el almacenamiento en caché esté funcionando como pretende, de modo que los usuarios no vuelvan a solicitar páginas innecesariamente.

También hay un buen artículo sobre el rendimiento de ASP.NET que es posible que desee leer en http://aspalliance.com/1533_ASPNET_Performance_Tips.7.

Exención de responsabilidad: Trabajo para Red Gate, que fabrica ANTS.

Answer 4

Encontré una manera fácil de ver lo que sucede en el servidor. Sin embargo, la forma profesional es probablemente utilizar una herramienta de creación de perfiles.

¿Qué hice? En la consola de IIS, puede obtener una lista de todos los subprocesos de trabajo actuales y, si elige uno, puede ver en qué está trabajando este subproceso. Así que pude ver que el hilo manejaba 100 solicitudes en paralelo, 70 de las cuales se remontaban a la misma llamada ajax.

La solución inmediata fue reducir la frecuencia de esa llamada (de cada 10 a cada 30 segundos). El siguiente paso será optimizar aún más la llamada en el lado del servidor, ya que tengo otras llamadas ajax con la misma frecuencia (cada 10 segundos) que casi nunca aparecían en la lista de solicitudes activas, ya que eran muy rápidas.