asp.net - studio - ¿Cómo "calentar" Entity Framework? ¿Cuándo se pone "frío"?

entity framework visual studio 2017 (5)

No, la respuesta a mi segunda pregunta no es el invierno.

Prefacio:

He estado investigando mucho en Entity Framework recientemente y algo que me sigue molestando es su rendimiento cuando las consultas no se calientan, lo que se denomina consultas frías.

Revisé el artículo de consideraciones de rendimiento para Entity Framework 5.0. Los autores introdujeron el concepto de consultas cálidas y frías y cómo difieren, que también noté yo mismo sin saber de su existencia. Aquí probablemente valga la pena mencionar que solo tengo seis meses de experiencia a mis espaldas.

Ahora sé en qué temas puedo investigar si quiero entender mejor el marco en términos de rendimiento. Lamentablemente, la mayor parte de la información en Internet está desactualizada o abarrotada de subjetividad, por lo tanto, no puedo encontrar información adicional sobre el tema Warm vs Cold questions.

Básicamente, lo que he notado hasta ahora es que cada vez que tengo que volver a compilar o los resultados de reciclaje, mis consultas iniciales se vuelven muy lentas. Cualquier lectura posterior de datos es rápida ( subjetiva ), como se esperaba.

Iremos migrando a Windows Server 2012, IIS8 y SQL Server 2012 y, como Junior I, en realidad me gané la oportunidad de probarlos antes que el resto. Estoy muy feliz de que hayan presentado un módulo de calentamiento que preparará mi aplicación para esa primera solicitud. Sin embargo, no estoy seguro de cómo proceder con el calentamiento de mi Entity Framework.

Lo que ya sé que vale la pena hacer:

Genera mis Vistas por adelantado según lo sugerido.
Eventualmente mueva mis modelos en un ensamble por separado.

Lo que considero hacer, yendo con sentido común, probablemente enfoque incorrecto :

Hacer lecturas de datos ficticios en Application Start para calentar, generar y validar los modelos.

Preguntas:

¿Cuál sería el mejor enfoque para tener alta disponibilidad en mi Entity Framework en cualquier momento?
¿En qué casos se vuelve "frío" el Entity Framework? (Recompilación, Reciclaje, reinicio de IIS, etc.)

Como ha indicado, use "vistas generadas previamente" que es todo lo que necesita hacer.

Extraído de su enlace : "Cuando se generan vistas, también se validan. Desde el punto de vista del rendimiento, la gran mayoría de la generación del costo de visualización es en realidad la validación de las vistas"

Esto significa que el golpe de rendimiento tendrá lugar cuando construya su conjunto de modelo. Su objeto de contexto saltará la "consulta en frío" y se mantendrá receptivo durante la duración del ciclo de vida del objeto de contexto, así como los nuevos contextos de objetos posteriores.

La ejecución de consultas irrelevantes no servirá para otro fin que consumir recursos del sistema.

El atajo ...

Omita todo ese trabajo adicional de vistas pregeneradas
Crea tu contexto de objeto
Despídase de esa dulce consulta irrelevante
Luego solo mantenga una referencia al contexto de su objeto durante la duración de su proceso (no recomendado).

Consejos generales.

Realice un registro riguroso que incluya a qué se accede y solicite tiempo .
Realice solicitudes ficticias al inicializar su aplicación para calentar las solicitudes muy lentas que retoma del paso anterior.
No se moleste en optimizar a menos que sea un problema real, comuníquese con el consumidor de la aplicación y pregunte. Siéntete cómodo teniendo un ciclo de retroalimentación continuo solo para descubrir qué necesita la optimización .

Ahora explique por qué las solicitudes ficticias no son el enfoque equivocado .

Menos complejidad : está calentando la aplicación de una manera que funcionará independientemente de los cambios en el marco, y no necesita averiguar API funky / funcionalidades marco para hacerlo de la manera correcta .
Mayor cobertura : está calentando todas las capas de almacenamiento en caché a la vez relacionadas con la solicitud lenta.

Explicar cuándo un caché se pone "frío".

Esto sucede en cualquier capa en su marco que aplique un caché, hay una buena descripción en la parte superior de la página de rendimiento .

Cuando alguna vez un caché tiene que ser validado después de un cambio potencial que hace que el caché caduque, esto podría ser un tiempo de espera o más inteligente (es decir, el cambio en el elemento en caché).
Cuando se desaloja un elemento de caché, el algoritmo para hacerlo se describe en la sección "Algoritmo de desalojo de caché" en el artículo de rendimiento que se ha vinculado , pero en breve.
- Caché LFRU (con la frecuencia más baja utilizada recientemente) en recuento de aciertos y edad con un límite de 800 elementos.

Las otras cosas que mencionó, específicamente la recompilación y el reinicio de IIS borran partes o todas las memorias caché en memoria.

No tengo experiencia en este marco. Pero en otros contextos, por ejemplo, Solr, las lecturas completamente falsas no serán de mucha utilidad a menos que puedas almacenar en caché todo el DB (o índice).

Un mejor enfoque sería registrar las consultas, extraer las más comunes de los registros y usarlas para calentar. Solo asegúrese de no registrar las consultas de preparación o eliminarlas de los registros antes de continuar.

Si busca el máximo rendimiento en todas las llamadas, debe considerar su arquitectura cuidadosamente. Por ejemplo, podría tener sentido precachear búsquedas frecuentes en la RAM del servidor cuando la aplicación se carga en lugar de usar llamadas a la base de datos en cada solicitud. Esta técnica asegurará tiempos mínimos de respuesta de la aplicación para datos comúnmente utilizados. Sin embargo, debe asegurarse de tener una política de caducidad de buen comportamiento o siempre borrar su caché cada vez que se realicen cambios que afecten a los datos en caché para evitar problemas con la concurrencia.

En general, debe esforzarse por diseñar arquitecturas distribuidas para que solo requieran solicitudes de datos basadas en IO cuando la información almacenada en caché local queda obsoleta o tiene que ser transaccional. Cualquier solicitud de datos "por cable" normalmente tomará entre 10 y 1000 veces más tiempo de recuperación que un local, en la recuperación de memoria caché. Este único hecho a menudo hace que las discusiones sobre "datos fríos vs. cálidos" no tengan consecuencias en comparación con el problema de los datos "locales vs. remotos".

¿Cuál sería el mejor enfoque para tener alta disponibilidad en mi Entity Framework en cualquier momento?

Puede elegir una combinación de vistas pregeneradas y consultas compiladas estáticas.

Static CompiledQuerys son buenos porque son rápidos y fáciles de escribir y ayudan a aumentar el rendimiento. Sin embargo, con EF5 no es necesario compilar todas sus consultas ya que EF compilará las consultas automáticamente. El único problema es que estas consultas pueden perderse cuando se barre la memoria caché. Por lo tanto, aún desea mantener referencias a sus propias consultas compiladas para aquellas que están ocurriendo solo muy raramente, pero que son costosas. Si coloca esas consultas en clases estáticas, se compilarán cuando se requieran por primera vez. Esto puede ser demasiado tarde para algunas consultas, por lo que es posible que desee forzar la compilación de estas consultas durante el inicio de la aplicación.

Las vistas pregeneradas es la otra posibilidad como usted menciona. Especialmente, para aquellas consultas que tardan mucho en compilarse y que no cambian. De esta forma, mueve la sobrecarga de rendimiento del tiempo de ejecución para compilar el tiempo. Además, esto no introducirá ningún retraso. Pero, por supuesto, este cambio pasa a la base de datos, por lo que no es tan fácil de tratar. El código es más flexible.

No use una gran cantidad de herencia TPT (que es un problema de rendimiento general en EF). Ni construyas tus jerarquías de herencia demasiado profundas ni demasiado amplias. Solo 2-3 propiedades específicas para alguna clase pueden no ser suficientes para requerir un tipo propio, pero podrían manejarse como propiedades opcionales (nulables) para un tipo existente.

No te aferres a un solo contexto por mucho tiempo. Cada instancia de contexto tiene su propio caché de primer nivel que ralentiza el rendimiento a medida que crece. La creación de contexto es barata, pero la gestión del estado dentro de las entidades en caché del contexto puede ser costosa. Las otras cachés (plan de consulta y metadatos) se comparten entre contextos y morirán junto con el dominio de la aplicación.

En general, debe asegurarse de asignar contextos con frecuencia y usarlos solo durante un corto período de tiempo, puede iniciar su aplicación rápidamente, compila consultas que rara vez se utilizan y proporciona vistas pregeneradas para consultas que son críticas para el rendimiento y que a menudo se utilizan.

¿En qué casos se vuelve "frío" el Entity Framework? (Recompilación, Reciclaje, reinicio de IIS, etc.)

Básicamente, cada vez que pierdes tu AppDomain. IIS realiza reinicios cada 29 horas , por lo que nunca puede garantizar que tendrá instaladas sus instancias. También después de un tiempo sin actividad, AppDomain también se cierra. Deberías intentar subir rápidamente de nuevo. Tal vez pueda hacer parte de la inicialización de forma asincrónica (pero tenga cuidado con los problemas de subprocesos múltiples). Puede usar tareas programadas que llaman a páginas ficticias en su aplicación en momentos en que no hay solicitudes para evitar que el dominio de aplicación muera, pero eventualmente lo hará.

También asumo que cuando cambias tu archivo de configuración o cambias los ensamblajes, habrá un reinicio.