La mejor solución para almacenar en caché

Question

¿Cuál es el mejor lugar para implementar el almacenamiento en caché en una aplicación basada en web?

• En la capa de presentación (¿no?)
• En la capa de lógica de negocios?
• En la capa de datos?

Voy a usar algo como memcached o MS Velocity debajo del capó.

Acabo de encontrarme escribiendo tanto código para actualizar el caché aquí y allá en la capa de lógica de negocios, entonces ¿sería mejor crear un entramado entre la capa de acceso a datos en el Servidor de Base de Datos para almacenar datos?

Creo que estas complicaciones se deben al hecho de que la mayoría de los datos que almacenamos en caché son específicos del usuario y estamos duplicando datos en la caché. Luchamos por encontrar la mejor solución.

Answer 1

caché es una parte importante o una aplicación web, pero no existe una solución mágica que se ajuste a cada proyecto. Trabajar en optimizaciones antes de que tu aplicación funcione es una mala idea. Antes de preguntarse dónde debe implementar una capa de caché, el primer paso es asegurarse de que su aplicación funcione bien (aunque sea lentamente) sin ninguna optimización de caché.

Cuando se alcanza este primer paso, puede comenzar a perfilar la aplicación, enumerando las funciones que parecen usar muchos recursos (ya sea CPU, memoria, E/S, acceso a la base de datos) o tomar muchas tiempo para completar (generalmente debido a los mismos síntomas).

Una vez que tenga una lista de características que usted piensa que puede ser optimizado con un sistema de caché, hay dos cuestiones que hay que preguntarse:

• "¿Cómo puedo mejorar todas estas características en el mismo time "(macro focus): una respuesta obvia a esta suele ser la caché de acceso a datos. Por lo general, no desea enviar la misma consulta al servidor de su base de datos una y otra vez si los datos que obtiene a cambio son siempre los mismos. Por lo tanto, almacenar esta clase de datos en caché, con una vida útil inteligente, siempre será una buena idea.

• "Cómo puedo mejorar cada función" (micro focus): Esto es complicado, y necesita comprender muy bien su aplicación para resolver esto. Algunos datos pueden almacenarse en caché, otros no, algunos no. Por lo general, un depurador y un generador de perfiles son excelentes herramientas para este paso, ya que lo ayudan a estar seguro de por qué una característica es lenta y le dan pistas sobre cómo deben optimizarse.

Las optimizaciones que vas a averiguar podría estar relacionado con cualquier capa de la aplicación (presentación, lógica de negocio, datos), pero eso no quiere decir que usted debe aplicar a todos ellos. Hay varias cosas importantes que debe tener en cuenta:

• ¿Esta característica realmente necesita ser optimizada? (¿Es una ganancia notable para el cliente? Para el hardware? Para toda la aplicación? Para otras aplicaciones?)
• ¿Qué ganancia de rendimiento puedo lograr? (1%, 200%, ...)
• ¿Cuánto tiempo tardaré en optimizarlo? (1 hora, 12 días, ...)
• ¿Qué tan riesgoso es optimizarlo? (¿Podría romper las cosas para la aplicación? Para el cliente?)

Una vez que tenga las respuestas a estas preguntas, es hora de hablar de esto con su jefe de proyecto, con sus colegas, o incluso con personas que don No trabaje en la aplicación con usted. Tener una opinión neutral es bueno, además de tener opiniones no técnicas (o menos técnicas). Hablar con estas personas debería ayudarlo a descubrir qué se debe hacer y qué no.

En este momento debe tener una lista de optimizaciones que es bastante clara, que ha pensado varias veces, y no debería tener problemas para codificarlas y probarlas.

Answer 2

caché: implementado en la capa de acceso a datos, acceder por la capa de lógica de negocios.

esto significa que debe tener cuidado con el caché que se está agotando.

Answer 3

Capa de datos: todas las capas sobre esta capa no necesitan saber de dónde provienen los datos. También solo almacenaría en caché los datos que no son muy volátiles, o incluiría alguna política de caducidad.

Answer 4

Lo implementamos en la capa de lógica de negocios entre las interacciones con la capa de presentación. Si se recibe una solicitud de la capa de presentación y se almacena en caché, entonces podemos omitir una gran cantidad de lógica y acceso a los datos.

Recomiendo encarecidamente MemCached por encima de MS Velocity, ¡la velocidad le costó configurarlo!

Answer 5

Capa de datos. Pero es confuso porque usamos el almacenamiento en caché de ASP.NET. Con su capacidad de expiración y dependencia, es bastante útil. Por lo tanto, nuestra capa empresarial no tiene idea de que la capa de datos podría estar almacenando en caché, ¡pero la capa de datos utiliza una tecnología de capa de presentación para el almacenamiento en caché! :(

Answer 6

Si va a almacenar en caché los objetos de negocio, y teniendo en cuenta los 3 niveles que usted describe que está utilizando, la capa de negocio es el lugar obvio.

Una configuración sencilla sería (para un solo objeto de negocio) :

1. MyCache es una clase estática
2. un método estático: MyCache.Retrieve (id), devuelve un objeto
3. La clase utiliza una estática Dictionary para el almacenamiento, y una estática ReaderWriterLock

El método Recuperar entonces realiza lo siguiente:

1. es el ID en la memoria caché (una de Dictionary/Identificación del objeto)?
2. Sin
   • agarrar el objeto de la base de datos
   • AquireWriterLock del ReaderWriterLock (¿por qué ReaderWriter? Porque no se está escribiendo con frecuencia, pero que está leyendo a menudo)
   • agregar el objeto a la memoria caché
3. Sí
   • recuperar el objeto del diccionario

Esa es mi solución preferida, se puede añadir tiempos de espera, compensación y así sucesivamente si es necesario. O use memcached o Microsoft Enterprise Library Caching Block pero generalmente son exagerados.

Answer 7

No puedo hablar de cosas específicas de ASP.NET, pero generalmente he encontrado que puede almacenar en caché en cada nivel. Su nivel de datos almacenará las respuestas de datos, su capa de presentación puede encontrar la necesidad de almacenar en caché los elementos de presentación generados (por ejemplo, hojas de estilo específicas del usuario), etc. En la mayoría de los casos, el nivel de datos es el usuario de caché más pesado y los otros niveles un caché de objetos si se demuestra que es necesario.

Lo más difícil es conseguir que la invalidación de caché funcione correctamente. Los caches añejos son un gran dolor de cabeza durante el despliegue. Asegúrese de averiguar cómo va a administrar la vida útil de cada objeto de caché. Los cachés LRU funcionan bien para el almacenamiento en caché de elementos estáticos según la demanda. Sin embargo, la mayoría de los cachés de datos necesitarán un ciclo de vida explícito, ya sea basado en un temporizador de vencimiento o vinculado a algún tipo de sesión de usuario.

Answer 8

El almacenamiento en caché es una optimización del rendimiento, por lo que lo hace donde está el cuello de botella. Ya sabes dónde está el cuello de botella midiéndolo tres veces y luego una vez más.

Tenga cuidado con la consistencia relajada de sus datos cuando almacena en caché, p. no desea almacenar en caché toda su aplicación de comercio de acciones.

Answer 9

Debería considerar el almacenamiento en caché a CADA capa.

El mejor lugar para almacenar en caché es lo más cercano posible a la solicitud del cliente (por lo que debe hacer el menor trabajo posible para atender la respuesta). En las aplicaciones web, sí en la capa de presentación, en la capa empresarial y en la capa de datos.

(Nota: Si usted está básicamente salpicando su código de lógica de negocio con la lógica de almacenamiento en caché de aquí para allá, realmente debería mirar en seperation of concerns para evitar su código de convertirse en una gran bola de barro :-))