Codemotion: descubriendo las cachés
•Télécharger en tant que PPTX, PDF•
1 j'aime•386 vues
Descubriendo las caches por Quique Martínez y Fernando Escolar. Hoy en día en la nube puedes hospedarlo todo, incluso la memoria caché que usan tus aplicaciones. Pero no todas las cachés que encontramos son iguales, ni se usan para los mismos fines, ni siquiera tienen el mismo comportamiento. A lo largo de esta charla realizaremos un viaje a través de los tipos de datos, cuales es mejor almacenarlos en caché y qué caché es más recomendabe para cada uno. Y terminaremos con los resultados de un estudio acerca de la performance de diferentes sistemas de cachés hospedados en la nube.
Recommandé
Recommandé
Contenu connexe
Similaire à Codemotion: descubriendo las cachés
Similaire à Codemotion: descubriendo las cachés (20)
Plus de Fernando Escolar Martínez-Berganza
Plus de Fernando Escolar Martínez-Berganza (20)
Dernier
Dernier (12)
Codemotion: descubriendo las cachés
- 1. MADRID · NOV 21-22 · 2014 Descubriendo las caches Quique Martínez Plain Concepts @quiqu3 Fernando Escolar Tokiota @fernandoescolar
- 2. MADRID · NOV 21-22 · 2014 Qué es una memoria caché
- 3. MADRID · NOV 21-22 · 2014 Tipos de caché Caché L1
- 4. MADRID · NOV 21-22 · 2014 Tipos de caché Caché L2
- 5. MADRID · NOV 21-22 · 2014 Tipos de caché Caché L3
- 6. Cache memory vs. no-memory MADRID · NOV 21-22 · 2014
- 7. MADRID · NOV 21-22 · 2014 Tipos de datos Datos de referencia
- 8. MADRID · NOV 21-22 · 2014 Tipos de datos Datos de actividad
- 9. MADRID · NOV 21-22 · 2014 Tipos de datos Datos de recursos
- 10. MADRID · NOV 21-22 · 2014 Tipos de datos Datos de referencia Datos de actividad Datos de recursos
- 11. MADRID · NOV 21-22 · 2014 Por qué usar caché Porque reducimos la latencia Latencia baja → respuesta rápida Respuesta rápida → más velocidad Más velocidad → cliente contento Cliente contento…
- 12. MADRID · NOV 21-22 · 2014 Por qué usar caché
- 13. MADRID · NOV 21-22 · 2014 Alternativas Más hierro Performance de procesos Usando agregados Variables de sesión Caché output
- 14. MADRID · NOV 21-22 · 2014 Pero… Escalar es caro Los procesos tienen límites Los agregados no son la panacea La sesión no es compartida El output lo gestiona el cliente
- 15. MADRID · NOV 21-22 · 2014 Caché distribuida Nuevos retos: Nuevo hierro Gestión Integración Escalabilidad Plan de contingencia …
- 16. MADRID · NOV 21-22 · 2014 Servicios caché en la nube
- 17. MADRID · NOV 21-22 · 2014 Cache as a Service
- 18. MADRID · NOV 21-22 · 2014 Azure Cache: AppFabric Cache Cache In-Role Azure Cache Services Virtual Machine Redis
- 19. TETING BEFORE DEPLOYING IS OVERRATED MADRID · NOV 21-22 · 2014
- 20. MADRID · NOV 21-22 · 2014 Resultados: Tech Mode Min. Put Max. Put Min. Get Max. Get Avg. Put Avg. Get Num. Operations Azure In-role Cache Memcached Shim Wrapper 1 4782 1 499 7 6 101027 Azure In-role Cache Memcached Gateway 0 217 0 20 3 2 101032 Azure Cache Service Azure SDK 0 16747 0 165 5 16 101020 Memcached VM Memcached 0 36 0 42 0 0 101020 Azure In-role Cache Local - Azure SDK 0 10308 0 77 3 4 101020 Azure Redis StackExchange
- 21. MADRID · NOV 21-22 · 2014
- 22. MADRID · NOV 21-22 · 2014 Muchas gracias!!! Quique Martínez Plain Concepts @quiqu3 Fernando Escolar Tokiota @fernandoescolar
Notes de l'éditeur
- Es un tipo de almacenamiento, pequeño, de acceso muy rápido que se utiliza en ingeniería de la computación para aportar una mayor velocidad al leer datos.
- Cache L1: en el procesador, muy rápida, pero pequeña. Es la memoria donde el procesador almacena los registros con los que hace operaciones.
- Cache L2: al lado de procesador, más grande pero más lenta. Aunque muy rápida. Es la típica caché que anuncian en los procesadores: i7 con 4kb de cache. Esta se usa como memoria intermedia, para almacenar más datos y luego volcarlos a la de nivel 1 para operar.
- Cache L3: memoria RAM o de disco (la ram es más rápida que el disco). Este es el nivel donde los vamos a mover a lo largo de la charla. Es la caché que como programadores de lenguajes manejados, estamos capacitados para gestionar. La memoria RAM a su vez tiene también una caché de acceso más rápido que la propia RAM, la SRAM, donde se almacenan los datos que más se usan. Y además puede usar la memoria de disco de la máquina si es que se ha llenado. Y los discos usan como caché el típico buffer que se usa al leer un archivo. Todo en los ordenadores usa siempre algún tipo de memoria caché :)
- - Una cache física (no-memory) es aquella caché que se persiste en una unidad de almacenamiento. Fisicamente quedará almacenada hasta que caduque. Un ejemplo es el outPut caché de una página web. Al usar estos parámetros, los browsers entienden que esos datos no se van a modificar. Así que los guarda y no los vuelve a pedir al servidor, usa la copia almacenada en su caché. Aunque apaguemos el ordenador, estos datos no se borran, la próxima vez que iniciemos, estarán allí. - La caché in-memory por otro lado, se almacena en la memoria RAM de la máquina. De forma que si reiniciamos la máquina, estos datos se borran y habrá que volverlos a cargar en la caché. Un ejemplo de esto sería el HttpRuntimeCache de asp.net: una caché que perdura en memoria y que gestiona por nosotros Asp.Net. Se le puede dar muchos usos, pero uno de los más típicos sería el ejemplo de un combo de países o ciudades. Datos que no suelen cambiar y que no queremos estar cargando constantemente de la base de datos. Los almacenamos en una memoria caché y accedemos a ellos de forma muy rápida.
- Datos de referencia: prácticamente de solo lectura. No se modifican demasiado y son comunes a todos los usuarios. Por ejemplo el listado de productos de una tienda virtual o los sprites/imagenes que luego se dibujan en pantalla en un videojuego.
- Datos de actividad: son datos de lectura y escritura fundamentalmente, cuyo ciclo de vida es el mismo que el de la sesión de un usuario. Por ejemplo el carrito de la compra de una tienda virtual, o la puntuación de un jugador en un videojuego.
- Datos de recursos: Son datos de lectura y escritura, compartidos por todos los usuarios, pero que pueden cambiar con frecuencia. Estos datos tienen la peculiaridad de poder ser accedidos por muchos usuarios. Un ejemplo sería el stockage de los productos de una tienda virtual, o las puntuaciones globales de todos los usuarios en un videojuego.
- En resumen: Está en manos del developer saber en cada momento y aplicación, qué datos sería mejor almacenar en qué tipo de caché. No hay una fórmula mágica para decidirlo, aunque sí algunos truquillos. Lo que sí hay que tener en cuenta es que una caché in-memory puede perder los datos en algún momento, por lo que no tenemos la seguridad de que estén ahí siempre, aunque los hayamos almacenado ahí al iniciar la aplicación...
- Porque reducimos la latencia. Si la latencia es baja, las respuestas son más rápidas. Que las respuestas sean rápidas implica que la velocidad de la aplicación es mayor. Si tenemos una aplicación rápida, el usuario/cliente estará más contento. Y si el usuario/cliente está contento, significa que volverá a contar con nuestra aplicación o servicios de desarrollo.
- Y esto en definitiva va a repercutir en más dinero para nosotros.
- Escalando el sistema. Más hierro. Mejorando la performance de los procesos Almacenando y cargando agregados y no entidad por entidad Usando variables de sesión o la caché output del asp.net
- Escalar es caro. Los procesos están limitados por la tecnología y los sistemas. Almacenar agregados, tampoco nos va a aportar una velocidad tan grande, aunque es muy recomendable. Las variables de sesión están solo disponibles para una instancia de una aplicación concreta, no para todas. La caché output, la gestiona el cliente bajo unas directrices del servidor, pero no podemos borrarla bajo demanda. Solo el propio cliente es el que la puede manejar.
- Así que una solución para esto sería el uso de un sistema de Caché distribuido. Pero manejar y darle disponibilidad a un sistema de caché distribuido puede ser un problema: nuevo hierro, problemas de gestión, hay que ver cómo integrarlo, tener un plan de escalabilidad y otro de contingencia para posibles problemas que surjan…
- Y es aquí donde vemos que una gran solución para esto es usar servicios de caché en la nube
- - Azure Cache (deprecated, pero mola hablar de ella. Es la de appFabric) Si de hecho, funciona muy bien como cluster.. - Azure Cache InRole - Azure Cache Services - VM: cualquier sistema de cache, memcached. - Redis: el uso definitivo? Yo lo preguntaría
- Lo hemos probado