servidores - La aplicación web de Azure(ASP.NET MVC) se enfría cada diez minutos y tarda más de 10-20 en cargarse

servidores asp net

Question

Tengo un problema muy extraño con una aplicación web de Azure y me siento bastante frustrado con eso.

Experimentamos que nuestra aplicación es muy rápida y sensible cuando la usamos, sin embargo, si no la usamos durante aproximadamente diez minutos, tiene un inicio muy frío (~ 10-20 segundos). Este arranque en frío solo ocurre cuando se trata de la base de datos. Cuando es un poco como cuando lanzamos la aplicación web.

Nuestros intentos

Usando Application Insights dentro de Azure, hemos configurado este ping cada 5 minutos:

Los valores atípicos siempre son causados ​​por mis implementaciones (que no utilizan ranuras de implementación en este momento). Sin embargo, esta página de inicio de sesión no llama a nuestra base de datos, por lo que no vemos el inicio "frío" en estos datos.

La configuración de la aplicación debe ser sólida. Nuestra aplicación web está alojada en el norte de Europa con Always on :

Acabamos de trasladar toda la configuración a un nuevo plan de servicio de aplicaciones / grupo de recursos, para asegurarnos de que nuestro problema estuviera enredado con nuestras otras aplicaciones. El nuevo plan de servicio de aplicaciones es un Standard 1 small , que no debería ser un problema. En cuanto a nuestro consumo, no estoy preocupado, y probablemente incluso podría probar un servicio más pequeño que haré después de resolver nuestro problema:

Nuestra base de datos SQL también está alojada en el norte de Europa (verificamos las ubicaciones mil millones de veces porque he cometido ese error anteriormente).

Al igual que con el servicio de aplicaciones, hemos elegido un hardware "demasiado grande" para asegurarnos de que no esté causando el problema (las DTU estándar S0: 10). El uso es ridículamente bajo:

Usamos la implementación continua ( Deployment options dentro del menú de Azure), pero mirando las implementaciones, no debería implementar algo constantemente:

La frustración que viene en la aplicación es muy receptiva cuando funciona. Cuando está "caliente", cada página se carga en segundos, al igual que mi tiempo de respuesta promedio se muestra en nuestra aplicación web:

Pero estos números son simplemente erróneos cuando nosotros (o nuestros usuarios!) Usamos nuestra aplicación. Aquí experimentamos que es muy a menudo una carga de + 10-20 segundos la primera vez.

¿Alguien tiene alguna idea? ¿Alguna pista? No tienes idea de lo agradecido que estaré.

EDITAR Y ACTUALIZAR 1:

He decidido configurar algunas pruebas más. Ahora he logrado obtener los datos reales que muestran nuestro problema llamando a otra página. Irónicamente, esta página NO llama a la base de datos, así que aunque pensé que esto era un problema de la base de datos, no parece ser así. Mira el reto aquí (la tendencia continúa +24 horas).

Es extraño lo estable que está siendo exactamente ~ 10 segundos. Y la tendencia no parece ser cada 10-20 minutos, sino más cerca de cada 5 minutos, con exactamente el mismo intervalo entre ellos:

EDITAR Y ACTUALIZAR 2:

He estado cavando un poco más. Resulta que hay un par de ideas muy interesantes: las llamadas "lentas" de 11 segundos desde la edición 1, son solo desde el este de EE. UU. Y desde un punto final ( http://prntscr.com/jcv69w ), y

Lo más interesante que encontré es lo siguiente:

La aplicación en sí no tiene ningún almacenamiento en caché. Yo uso Entity Framework, y supongo que uso algo de caché, pero eso es todo.

Me registré en nuestra aplicación y hice clic en Chrome. Descubrí que las páginas que ya había visitado se mostraban instantáneamente (con datos de DB), pero si abría una página nueva, se cargaría lentamente. Parecía que algunas entidades se almacenaban en caché la primera vez que abría una página.

Luego intenté abrir la aplicación en un nuevo navegador. Si abriera una página que había abierto anteriormente en Chrome, se abriría instantáneamente. Si abriera una página nueva en la que no había hecho clic antes, tendría una carga de ~ 10 segundos.

Mi mejor conjetura ahora es que el Entity Framework que uso está dando problemas por alguna razón.

EDITAR 3:

Acaba de agregar una recompensa, y está configurando una gran cantidad de registros. He agregado el MiniProfiler, pero tengo problemas para que funcione en producción (solo se muestra en las solicitudes locales).

También he agregado el registro en global.asax para Application_Start y Application_BeginRequest y Application_EndRequest para ver algunos y el estado allí. Se actualizará con los resultados pronto.

EDITAR 4:

Así que ahora tengo los primeros números interesantes en. La aplicación no está siendo reciclada. Application_Start solo se llama una vez.

Puedo ver la diferencia horaria al iniciar sesión en EndRequest y BeginRequest . Puedo ver que hay varias llamadas que demoran más de +15 segundos entre estas dos ... Pero cuando el sitio está cálido, toma ~ 0.5-2 segundos dependiendo de la página. Entonces, algo muy extraño está sucediendo entre el principio y el final de la solicitud. Depurando más!

EDIT 5:

Tengo MiniProfiler para trabajar. Aquí hay un ejemplo de la carga lenta (~ 15 segundos):

Mi siguiente paso es agregar el seguimiento de Entity Framework e incluso más líneas para llamadas de línea. Estoy recibiendo mi dinero en la base de datos!

EDIT 6:

Okidoki, estaba equivocado. es el método de renderizado que es lento, ¡no la base de datos! NO tengo idea de cómo depurar esto ... ¡ Al google!

EDITAR 7:

Tiempo para otra actualización. Estado es: nada ha sido resuelto.

Así que he probado muchas cosas:

1) Intenté deshabilitar todos los tipos de almacenamiento en caché ( Evitar el almacenamiento en caché en ASP.NET MVC para acciones específicas usando un atributo ) y tengo el mismo comportamiento. Primera carga? Lento. Siguiente carga? Rápido. Espere 5-10 minutos, mismo comportamiento por lo que no se resuelve.

2) Tenía algunas cosas personalizadas en mi archivo startup.auth con un retraso de 5 minutos. Remoto. No es el problema.

3) Utilicé un atributo personalizado para la autorización. Quité eso.

4) Actualicé la implementación de Entity Framework para que funcione según la solicitud

Estoy realmente frustrado. Mi siguiente paso es:

A) Intente hacer 5-10 versiones de la misma página (sin _layout, con diseño, con base de datos, sin base de datos, con inyección de dependencia, sin ... todas estas cosas), así que vea si puedo encontrar un patrón.

B) Intente mover el alojamiento a una máquina virtual para ver si resuelve el problema

EDIT 8 - NUEVA RELIJA AÑADIDA:

Ahora he añadido New Relic. Dos cosas muy aterradoras son las siguientes (¡Encontré y reproduje el error!):

Y en cuanto al frontend (parte del navegador de New Relic), hay una falta de ~ 15s entre dos inicios:

http://prntscr.com/jevgeg vs http://prntscr.com/jevgix con nada entre medio.

Answer 1

1. Separe cualquier cosa de la implementación frente a la local. Si la aplicación se ejecuta perfectamente en el entorno local, entonces ocurre algo diferente cuando se dirige a Azure. Resolver algo está tomando mucho tiempo.
2. Cualquier recurso estático (secuencia de comandos, estilos, etc.) se almacena automáticamente en el caché en la primera solicitud, por lo que en la solicitud posterior, el problema no debería surgir.
3. Como sabe que el método "Render" está dando el problema, parece un complejo cálculo de anidamiento y está ocurriendo la manipulación de DOM del navegador. Sin embargo, si esto no es un desafío cuando está en local, entonces verifique si la representación requiere recursos externos y ellos reciben llamadas de bloqueo (puede que necesiten un uso intensivo de ajax o de las llamadas asíncronas del lado del servidor, aunque supongo que ya lo tendría puesto).
4. Es posible que se requiera una refactorización (para tener pilas más pequeñas y posible uso de subprocesos / IO sin bloqueo), sin embargo, es necesario que vea su código para sugerirlo.

Comparte el evento de carga de tu página y cualquier llamada posterior realizada por él. Además, cómo se representa la vista junto con cualquier manejo de DOM.

Answer 2

¿Está compilando Less o Sass en su configuración de agrupación?
En caso afirmativo, ¿qué JavaScriptEngineSwitcher está utilizando?
Recuerdo haber tenido un problema similar. Los paquetes se compilan en el primer acceso y tomaba una gran cantidad de tiempo.
La solución fue cambiar al motor V8.

Answer 3

Algunas ideas:

1. En la hoja de la aplicación web, vaya al menú Diagnosticar y resolver problemas. Luego haga clic en los contadores de rendimiento. Honestamente, pesco en cada uno de los contadores de rendimiento disponibles, prestando atención a la línea de tiempo frente a su rendimiento degradado. Una vez me enteré de que SignalR estaba ahogando mi servidor debido a conexiones fuera de control al ver el recuento de subprocesos.

2. ¿Está limpio el registro de errores del servidor en Application Insights?

3. En la pantalla Diagnosticar y resolver problemas, ¿ve algo sospechoso en los registros de seguimiento de solicitudes fallidas?

Answer 4

Estoy publicando una respuesta a pesar de que no está resuelta, pero estoy 99% seguro de haber encontrado el problema subyacente.

Lo que pasa es que cuando lanzo, cada vista necesita ser construida. Se tarda unos 15 segundos en construir una vista, que es lo que New Relic también muestra en mi última actualización.

Esto trae dos soluciones temporales y una pregunta más importante: ¿por qué la construcción de la vista es tan lenta?

Las soluciones temporales son simples. Compile las vistas al lanzar o visite las páginas más importantes justo después de un lanzamiento. Esto obviamente es molesto porque lo libero varias veces al día.

El motivo por el que es tan lento, supongo, es porque estoy usando un tema muy grande de Bootstrap. La forma en que estoy manejando los paquetes no es muy eficiente, lo que podría proporcionar un problema.

La razón por la que pensé que el dolor era que el sitio estaba lento después de unos 10 minutos era simplemente porque solía publicar un nuevo código con bastante frecuencia y no visitaba una gran parte de nuestras páginas. Después de hacer esto, es rápido.

Muchas gracias por su ayuda y apoyo, al menos ahora puedo lidiar con eso.

Answer 5

Hay dos opciones más para encontrar y arreglar.

1. Usuario New Relic para rastrear.

Consulte this publicación de hanselman sobre su uso en Azure .

2. Siga las mejores prácticas de Asp.Net MVC

Revisa this post para las mejores prácticas.

También para las lecturas de datos, puede usar ADO.NET con procedimientos almacenados en lugar de Entity Framework , porque a partir de ahora EF puede tener algunos problemas de rendimiento.

Answer 6

Tengo un par de respuestas posibles.

Entity framework primero-código / inicialización de la base de datos: si está usando la configuración del código por primera vez con migraciones y posiblemente datos iniciales, cada una de estas cosas puede causar algunos problemas de "calentamiento".

Especialmente si no está inicializando la base de datos en el inicio de la aplicación, eso significaría que la primera vez que golpee su base de datos es cuando se inicializa.

Versión de Entity Framwork: Entity Framework también ha tenido muchas mejoras de rendimiento en 5 y 6.x, algunas de estas también tienen que ver con velocidades de arranque en frío y en caliente.

Las vistas no están precompiladas: si obtiene cargas lentas en las páginas (como después de la implementación) cada primer golpe de una página nueva (vista), y luego las cargas posteriores están bien. Esto puede deberse a que las páginas no están compiladas, puedo desarrollar eso si ese es el caso.

Reciclaje Parece que está experimentando estos problemas cuando la aplicación se recicla, y no es la inicialización automática (por lo que recibe ese golpe frío) los peores problemas de rendimiento que he visto con estas cosas suelen estar relacionados con el marco de la entidad y la precompilación. Pero ambos se pueden arreglar fácilmente. Pero asegurarse de que la aplicación esté "siempre funcionando" y que se inicialice automáticamente después del reciclaje también garantiza que ningún usuario reciba este golpe frío.

ACTUALIZACIÓN: Como estaba relacionado con la vista, puedo ofrecer una solución que he encontrado muy útil. Instalación del paquete RazorGenerator.Mvc Nuget. Y agregar este motor como el primer motor asegurará que uses vistas compiladas.

En App_Start puedes crear un archivo llamado RazorGeneratorMvcStart.cs con contenido como este:

using RazorGenerator.Mvc;
[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(MyNamespace.RazorGeneratorMvcStart), "Start")]
namespace MyNamespace {
public static class RazorGeneratorMvcStart {
public static void Start() {
ViewEngines.Engines.Insert(0, new PrecompiledMvcEngine(typeof(RazorGeneratorMvcStart).Assembly));
VirtualPathFactoryManager.RegisterVirtualPathFactory(engine);
}
}
}

El motor de la maquinilla de afeitar puede incluso tomar un parámetro para UsePhysicalViewsIfNewer para aquellos a los que les gusta reemplazar una vista en vivo. En ese caso, utiliza la versión precompilada, a menos que se haya colocado en la carpeta una vista con una fecha más nueva que la .dll compilada.

Este enfoque debería resolver los problemas de rendimiento con vistas.