¿Cómo "calentar" Entity Framework? ¿Cuándo hace "frío"?
No, la respuesta a mi segunda pregunta no es el invierno.
Prefacio:
He estado investigando mucho sobre Entity Framework recientemente y algo que me sigue molestando es su rendimiento cuando las consultas no se calientan, las llamadas consultas frías.
Revisé el artículo consideraciones de rendimiento para Entity Framework 5.0. Los autores introdujeron el concepto de Cálido y Frío consultas y cómo difieren, que I también me noté sin saber de su existencia. Aquí probablemente vale la pena mencionar que solo tengo seis meses de experiencia a mis espaldas.
Ahora sé qué temas puedo investigar adicionalmente si quiero entender mejor el marco en términos de rendimiento. Desafortunadamente, la mayoría de la información en Internet está desactualizada o llena de subjetividad, de ahí mi incapacidad para encontrar información adicional sobre las consultas Warm vs Cold tema.
Básicamente lo que he notado hasta ahora es que cada vez que tengo que recompilar o los éxitos de reciclaje, mis consultas iniciales se están volviendo muy lentas. Cualquier lectura de datos posterior es rápida (subjetiva ), como se esperaba.
Estaremos migrando a Windows Server 2012, IIS8 y SQL Server 2012 y como Junior en realidad me gané la oportunidad de probarlos antes que el resto. Estoy muy contento de que hayan introducido un módulo de calentamiento que preparará mi aplicación para eso primero solicitud. Sin embargo, no estoy seguro de cómo proceder con el calentamiento de mi Entity Framework.
Lo que ya sé vale la pena hacer:
- Generar mis puntos de vista de antemano como se sugiere.
- Finalmente mover mis modelos en un conjunto separado.
Lo que considero hacer, yendo con sentido común, probablemente un enfoque equivocado :
- Haciendo lecturas de datos ficticios al inicio de la aplicación para calentar las cosas arriba, generar y validar el modelo.
Preguntas:
- ¿Cuál sería el mejor enfoque para tener alta disponibilidad en mi Entity Framework en cualquier momento?
- ¿En qué casos el Entity Framework se vuelve "frío" de nuevo? (Recompilación, Reciclaje, Reinicio de IIS, etc.)
5 answers
- ¿Cuál sería el mejor enfoque para tener alta disponibilidad en mi Entity Framework en cualquier momento?
Puede elegir una mezcla 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 autocompila las consultas por sí mismo. El único problema es que estas consultas pueden perderse cuando la caché barrer. Por lo tanto, aún desea mantener referencias a sus propias consultas compiladas para aquellas que solo ocurren muy raras, 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.
Pregenerating views es la otra posibilidad como usted menciona. Especialmente, para aquellas consultas que toman mucho tiempo para compilar y eso no cambia. De esta manera, se mueve la sobrecarga de rendimiento del tiempo de ejecución al tiempo de compilación. Además, esto no introducirá ningún retraso. Pero, por supuesto, este cambio va a través de la base de datos, por lo que no es tan fácil de tratar. El código es más flexible.
No use mucha herencia de TPT (eso es un problema de rendimiento general en EF). No construyas jerarquías hereditarias demasiado profundas ni demasiado amplias. Solo 2-3 propiedades específicas de alguna clase pueden no ser suficientes para requerir un tipo propio, pero podrían ser manejado como propiedades opcionales (nullable) a un tipo existente.
No te aferres a un solo contexto durante mucho tiempo. Cada instancia de contexto tiene su propia caché de primer nivel que ralentiza el rendimiento a medida que crece. La creación de contexto es barata, pero la gestión estatal dentro de las entidades en caché del contexto puede volverse costosa. Las otras cachés (plan de consulta y metadatos) se comparten entre contextos y morirán junto con el AppDomain.
Todo en todo usted debe hacer asegúrese de asignar contextos con frecuencia y usarlos solo por un corto tiempo, que puede iniciar su aplicación rápidamente, que compila consultas que rara vez se usan y proporciona vistas pregeneradas para consultas que son críticas para el rendimiento y que se usan a menudo.
- ¿En qué casos el Entity Framework se vuelve "frío" de nuevo? (Recompilación, Reciclaje, Reinicio de IIS, etc.)
Básicamente, cada vez que pierdes tu AppDomain. IIS realiza reinicios cada 29 horas , por lo que puede nunca garantice que tendrá sus instancias alrededor. También después de algún tiempo sin actividad, el AppDomain también se apaga. Usted debe tratar de llegar rápidamente de nuevo. Tal vez pueda hacer algunas de las inicializaciones de forma asíncrona (pero tenga cuidado con los problemas de subprocesos múltiples). Puede usar tareas programadas que llaman a páginas ficticias en su aplicación durante los momentos en que no hay solicitudes para evitar que el AppDomain muera, pero eventualmente lo hará.
También asumo cuando cambias tu configuración file or change the assemblies there's going to be a restart.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-03-26 09:03:09
Si está buscando el máximo rendimiento en todas las llamadas, debe considerar su arquitectura cuidadosamente. Por ejemplo, podría tener sentido precalentar búsquedas de uso frecuente en la memoria 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 garantizará tiempos mínimos de respuesta de la aplicación para los datos comúnmente utilizados. Sin embargo, debe asegurarse de tener una política de caducidad bien comportada o siempre borrar su caché cada vez que se realicen cambios que afecten los datos almacenados 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 E / s cuando la información almacenada localmente en caché se vuelva obsoleta o necesite ser transaccional. Cualquier solicitud de datos" a través del cable " normalmente tardará 10-1000 veces más en recuperarse que una local, en la recuperación de caché de memoria. Este hecho por sí solo a menudo hace que las discusiones sobre "datos fríos vs. cálidos" sean intrascendentes en comparación con el " local vs. remoto " problema de datos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-27 14:13:09
Consejos Generales.
- Realice registros rigurosos que incluyan qué se accedey tiempo de solicitud.
- Realice solicitudes ficticias al inicializar su aplicación a warm boot solicitudes muy lentas que recoge del paso anterior.
- No te molestes en optimizar a menos que sea un problema real, comunícate con el consumidor de la aplicación y pregunta. Póngase cómodo teniendo un bucle de retroalimentación continua aunque solo sea para averiguar lo que necesita optimización.
Ahora para explicar por qué las solicitudes ficticias no son el enfoque incorrecto.
- Menos Complejidad - Usted está calentando la aplicación de una manera que funcione independientemente de los cambios en el marco, y no es necesario averiguar posiblemente funky Api/marco interna de hacerlo de la manera correcta.
- Mayor cobertura - Está calentando todas las capas de almacenamiento en caché a la vez relacionadas con la lenta solicitud.
Para explicar cuando una caché se "enfría".
Esto sucede en cualquier capa en su marcoque aplica una caché, hay una buena descripción en la parte superior de la página de rendimiento.
- Cuando una caché tiene que ser validada después de un cambio potencial que la hace obsoleta, esto podría ser un tiempo de espera o más inteligente (es decir, un cambio en el elemento almacenado en caché).
- Cuando un elemento de caché es desalojado, el algoritmo para hacer esto se describe en la sección "Algoritmo de desalojo de caché" en el artículo de rendimiento que vinculó, pero en resumen.
- Caché LFRU (Menos utilizado recientemente) en número de visitas y antigüedad con un límite de 800 elementos.
Las otras cosas que mencionó, específicamente la recompilación y el reinicio de IIS limpian partes o todas las cachés en memoria.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-29 05:43:26
Como has dicho, usa "vistas pre-generadas" eso es realmente todo lo que necesitas hacer.
Extraído de su enlace: "Cuando se generan vistas, también se validan. Desde un punto de vista de rendimiento, la gran mayoría del costo de generación de vistas es en realidad la validación de las vistas"
Esto significa que el golpe de rendimiento tendrá lugar cuando construya su ensamblaje de modelo. Su objeto de contexto entonces saltará la "consulta fría" y permanecerá receptivo durante la duración de el ciclo de vida del objeto de contexto, así como los nuevos contextos de objetos posteriores.
Ejecutar consultas irrelevantes no servirá más que para consumir recursos del sistema.
El atajo ...
- Omita todo ese trabajo extra de vistas pre-generadas
- Crea tu contexto de objeto
- Dispara esa dulce consulta irrelevante
- Entonces solo mantenga una referencia a su contexto de objeto durante la duración de su proceso (no recomendado).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-28 21:12:53
No tengo experiencia en este marco. Pero en otros contextos, por ejemplo Solr, las lecturas completamente ficticias no serán de mucha utilidad a menos que pueda almacenar en caché toda la base de datos (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 calentamiento o eliminarlas de los registros antes de continuar.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-23 15:13:14