¿Cómo “calentar” Entity Framework? ¿Cuándo se pone “frío”?

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 comstackr 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 rest. 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? (Recomstackción, Reciclaje, reinicio de IIS, etc.)

  • ¿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 comstackdas estáticas.

Static CompiledQuerys son buenos porque son rápidos y fáciles de escribir y ayudan a boost el rendimiento. Sin embargo, con EF5 no es necesario comstackr todas sus consultas ya que EF comstackrá 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 comstackdas para aquellas que están ocurriendo solo muy raramente, pero que son costosas. Si coloca esas consultas en clases estáticas, se comstackrán cuando se requieran por primera vez. Esto puede ser demasiado tarde para algunas consultas, por lo que es posible que desee forzar la comstackció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 comstackrse y que no cambian. De esta forma, mueve la sobrecarga de rendimiento del tiempo de ejecución para comstackr 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, comstack 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? (Recomstackció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 progtwigdas 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.

Si busca el máximo rendimiento en todas las llamadas, debe considerar su architecture 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 architectures 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”.

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 …

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

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.