¿Está bien usar variables estáticas para almacenar información en caché en ASP.net?

Question

Por el momento estoy trabajando en una aplicación de administración de proyectos en C# 3.5 en ASP.net. Para reducir las visitas a la base de datos, estoy almacenando en caché mucha información usando variables estáticas. Por ejemplo, una lista de usuarios se mantiene en la memoria en una clase estática. La clase lee toda la información de la base de datos al inicio y actualiza la base de datos cada vez que se realizan cambios, pero nunca necesita leer desde la base de datos.

La clase hace ping a otros servidores web (si existen) con información actualizada al mismo tiempo que escribe en la base de datos. El mecanismo de ping es un servicio de Windows al que el objeto de caché se registra utilizando un puerto aleatorio disponible. Se usa para otras cosas también.

La cantidad de datos no es tan buena. En este momento lo estoy usando solo para almacenar en caché a los usuarios (hashes de contraseñas, permisos, nombre, correo electrónico, etc.). Simplemente guarda un montón de llamadas realizadas en la base de datos.

Me preguntaba si hay algún inconveniente para este método y/o si hay mejores formas de almacenar en caché los datos.

Answer 1

Una trampa: un campo estático tiene un ámbito por dominio de aplicación, y una mayor carga hará que el servidor genere más dominios de aplicación en el grupo. Esto no es necesariamente un problema si solo lee los datos estáticos, pero obtendrá datos duplicados en la memoria, y obtendrá un golpe cada vez que se crea o se recicla un dominio de la aplicación.

Es mejor usar el objeto Cache, está destinado para cosas como esta.

Editar: resulta que estaba equivocado acerca de dominios de aplicación (como se señala en los comentarios) - más instancias de la aplicación serán generados bajo carga, pero todos ellos se ejecutan en el mismo dominio de aplicación. (¡Pero aún debe usar el objeto Cache!)

Answer 2

Hmmm ... El método "clásico" sería el caché de la aplicación, pero siempre y cuando no actualizar las variables estáticas, o no entiende los problemas de bloqueo si lo hace, y entender que pueden desaparecer en cualquier momento con un reinicio dominio de aplicación entonces realmente no veo el daño al usar una estática.

Answer 3

Mientras pueda esperar que la memoria caché nunca alcance un tamaño mayor que la cantidad de memoria disponible, está bien. Además, asegúrese de que solo haya una instancia de esta aplicación por base de datos, o que las memorias caché en las diferentes instancias de la aplicación puedan "caer fuera de sincronización".

Donde trabajo, tenemos un O/RM de cosecha propia, y hacemos algo similar a lo que está haciendo con ciertas tablas que no se espera que crezcan o cambien mucho. Entonces, lo que estás haciendo no tiene precedentes, y de hecho en nuestro sistema, es probado y verdadero.

Answer 4

Otro inconveniente que debe tener en cuenta es la seguridad de los hilos. Todas sus solicitudes de aplicaciones se ejecutan en el mismo dominio de aplicación pero pueden aparecer en diferentes subprocesos. El acceso a una variable estática debe dar cuenta de que se accede desde múltiples hilos. Probablemente un poco más de lo que está buscando. El objeto de caché es mejor para este propósito.

Answer 5

Le sugiero que busque formas de tener un caché distribuido para su aplicación. Puede echar un vistazo a NCache o indeXus.Net

La razón por la que sugerí esto es porque usted creó su propia forma ad-hoc de actualizar la información que está almacenando en caché. Las variables estáticas/referencias están bien, pero no se actualizan/actualizan (por lo que tendrá que manejar el envejecimiento por su cuenta) y parece que tiene una configuración distribuida.