Tengo una implementación de carga bastante alta en Azure: 4 instancias grandes que atienden entre 300 y 600 solicitudes por segundo. En condiciones normales: el "Tiempo de respuesta promedio" es de 70 a 150 ms, pero a veces puede crecer hasta 200-300 ms, pero está absolutamente bien.
Sin embargo, una o dos veces al día (no en "Horas punta") veo esa imagen en la pestaña Supervisión del sitio web:
Por lo tanto, la cantidad de solicitudes por minuto disminuye significativamente, el tiempo de respuesta promedio aumenta a 3 minutos y, después de un tiempo, todo vuelve a la normalidad.
Durante este "Apagón", solo se descarta el 0,1 % de las solicitudes (Errores del servidor Http con tiempo de espera), otras solicitudes simplemente esperan en la cola y normalmente se procesan después de unos minutos. Sin embargo, no todos los clientes están listos para esperar :-(
El uso de la memoria es inferior al 30% todo el tiempo, el uso de la CPU es solo del 40-50%.
¿Qué ya he comprobado?:
¿Cuál podría ser la razón de tales problemas? ¿Qué puedo comprobar a continuación?
¡Gracias a todos de antemano!
Actualización 1 : BenV propuso algo bueno para probar, pero desafortunadamente no mostró nada :-(
Configuré procesos que reciclan cada 500 000 solicitudes y también agregué nodos de trabajo, por lo que la utilización de la CPU ahora es inferior al 40 % durante todo el día, pero siguen apareciendo apagones.
Actualización 2 : el proyecto utiliza ASP.Net MVC 4.
Tuve exactamente este mismo problema. Para mí, vi muchos errores de WinCache en mis registros.
Cada vez que el sitio fallaba, tendría muchos errores de WinCache en el registro. WinCache es cómo IIS maneja PHP para tratar de acelerar el procesamiento. Es un complemento creado por Microsoft que está habilitado de forma predeterminada en IIS y en todos los sitios de Azure. WinCache se bloqueaba y, en lugar de reciclar y continuar, consumía toda la memoria y los identificadores de archivos en una instancia, esencialmente bloqueándolos.
Agregué una nueva configuración de la aplicación en Azure Portal para escanear una carpeta en busca de cambios en la configuración de php.ini.
d:\inicio\sitio\ini
Se agregó un archivo en d:\home\site\ini\settings.ini que contiene lo siguiente
wincache.fcenabled=1 session.save_handler = files memory_limit = 256M wincache.chkinterval=5 wincache.ucachesize=200 wincache.scachesize=64 wincache.enablecli=1 wincache.ocenabled=0 wincache.fcenabled=1Habilita el almacenamiento en caché de archivos usando WinCache (creo que es el valor predeterminado de todos modos)
session.save_handler = filesCambia el controlador de sesión de WinCache (predeterminado de Azure) a un archivo estándar basado para reducir el estrés del motor de caché
memory_limit = 256M wincache.chkinterval=5 wincache.ucachesize=200 wincache.scachesize=64 wincache.enablecli=1Establece el tamaño de WinCache en 256 megabytes por subproceso y limita el tamaño total de la caché. Esto obliga a WinCache a borrar los datos antiguos y reciclar la memoria caché con más frecuencia.
wincache.ocenabled=0Este es el grande. DESHABILITAR el almacenamiento en caché del código operativo de WinCache. Eso es WinCache almacenando en caché los scripts PHP reales en la memoria. Los archivos aún se almacenan en caché desde la línea uno, pero PHP se interpreta normalmente y no se almacena en caché en archivos binarios grandes.
Pasé de tener un bloqueo de mi sitio web de Azure aproximadamente una vez cada 3 días con registros que se parecen a los suyos a 120 días seguidos hasta ahora sin ningún problema.
¡Buena suerte!
Hay algunas buenas herramientas disponibles para Web Apps en el portal de vista previa .
La extensión de Application Insights puede resultar especialmente útil para supervisar y solucionar problemas de rendimiento de la aplicación .