EF: Cache de consultas

Nota: La información aquí presente aplica a Entity Framework 6, en versiones anteriores el comportamiento puede ser diferente.

 

Uno de los elementos que más desapercibido suele pasar de todos los elementos de Entity Framework es su sistema de cache de consultas. Cada vez que escribimos una consulta en LINQ, ESQL o realizamos una operación con nuestro contexto de trabajo, aplica también a operaciones de mantenimiento, Entity Framework utiliza una cache de la compilación de los diferentes Command Tree que son ejecutados. Aunque en un principio la compilación de estos CQT no debería llevar mas de unas pocas milésimas de segundo, en ocasiones, este tiempo puede ser muy alto, dependiendo de lo complejo de nuestras consultas, por lo que mantener una cache de estas estructuras es un aporte de rendimiento importante. A lo largo de este post trataremos de ver como funciona internamente este sistema de cache con el fin de que podamos aprender un poco más de Entity Framework.

 

QueryCacheManager

 

QueryCacheManager es la clase encargada de realizar nuestra cache de consultas, en realidad, las entradas pueden ser de otra naturaleza, pero para el post, lo simplificaremos así. Esta cache está limitada en su número de elementos, en concreto a 1000 entradas, por lo tanto, podríamos decir que a lo sumo una solución solamente podría tener para cada tipo de contexto de trabajo, fíjese que no digo instancia, 1000 entradas cacheadas. En realidad, este número difícilmente se va a llegar a conseguir puesto que nuestra clase de cache tiene un proceso de eviction que limpiará estos elementos. El desahucio de entradas se hace mediante un simple temporizador que se ejecuta cada minuto y comprueba si se deben de retirar entradas de cache, con una técnica muy simple y efectiva que veremos a continuación.

 

El desahucio

 

Para que Entity Framework libere entradas de nuestra cache el sistema tiene que superar un limite de entradas, que está establecido al 80 %, es decir, 800 entradas. Cada vez que nuestro temporizador de eviction salta, comprueba si el número de entradas es superior a 800. En caso afirmativo comienza la limpieza basándose en una propiedad, HitCount, que nos da una idea de las veces que esas entradas han sido utilizadas. Cada vez que se comprueba si una consulta está o no en la cache, esta incrementa el valor de la propiedad anterior, por lo tanto las consultas más utilizadas tienen unos valores de HitCount más altos. El proceso de eviction libera de la cache todas las entradas con un HitCount igual a 0, pero ¿como llegan las entradas a tener un hitcount igual a cero? La respuesta se debe a que a mayores de eliminar las entradas con hitcount cero el proceso de eviction se dedica en cada pasada a envejecer las entradas, con un simple right-shift con factores 1,1,2,4,8,16. Este envejecimiento hace que siempre que estemos en entornos de alto uso de cache, más de 800 entradas, los elementos menos utilizados irán desapareciendo.

Aunque el número de entradas, 1000 elementos, no es algo seleccionado al azar, los diferentes tipos de soluciones con las que nos podemos enfrentar hace que este número no siempre pueda ser un número justo, modificarlo con el fin de aumentarlo podría introducir mejoras en el comportamiento de una solución en producción. Por desgracia, por ahora, este número es fijo y no disponemos de ninguna forma para parametrizarlo  y observar resultados. Lo mismo, en realidad, podríamos decir del valor de carga máxima de la cache, el 80 % como comentábamos, o del tiempo de pasada del proceso de eviction.

 

Espero que os ayude y se entienda un poco mejor como funcionan ciertas partes de EF.

 

 

Saludos

Unai

Un comentario sobre “EF: Cache de consultas”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *