Algo que aconsejamos siempre a nuestros clientes es la utilización de un buen caché en RAM. Especialmente cuando detectamos un cuello de botella en el acceso a la base de datos (en adelante BDD).

Casos habituales

Nos hemos encontrado con casos de cientos de conexiones a MySQL que se realizan para una sola página en una sola impresión. Esto quiere decir que para cada click de cada usuario en nuestra web estamos pidiendo cientos de querys, y algunas de ellas complejas y sin índices, a nuestra sufrida BDD. Haced una sencilla multiplicación, número de visitas por día por media de querys para generar una página.

Incluso en algunas aplicaciones se guarda en la BDD el número de veces que se ha servido una página, un fragmento, una imagen… Es decir, agravamos el problema con un montón de inserciones por impresión.

No estamos diciendo que todo eso no sea necesario, nuestros clientes conocen bien su lógica de negocio y saben perfectamente lo que necesitan almacenar y extraer de la base de datos. No, ese es tu trabajo, y lo haces bien o posiblemente habrías cerrado ya.

Lo único que estamos diciendo es que tal vez no necesitas actualizar todos esos valores directamente sobre la BDD, y tal vez no necesitas regenerar una información para cada click, sino que los valores pueden estar en memoria RAM e insertarlos una sola vez cada 5 ó 10 minutos. ¿Y las páginas que sirves? ¿Realmente necesitan regenerarse para cada click?

Esta lógica, bien adaptada, te va a servir para casi todo pero por poner un ejemplo sencillo, piensa en una página de información con tu dirección, una fotografía, un formulario de contacto y un texto. ¿Necesitas pedir esos datos a la BDD y que tu programa genere el HTML cada vez? Seguramente no, seguramente con que hagas esa operación una vez al día y guardes el resultado en RAM para servirlo de allí las siguientes ocasiones es suficiente.

Aún más, genéralo una vez y guárdalo en RAM para siempre, si modificas en tu backend esa información procura entonces que tu programa invalide el caché, bien tras el formulario o bien en el propio modelo de datos.

Una vez que tengas en la cabeza esta mecánica verás la cantidad de cosas que puedes mejorar con ella.

Soluciones

Hay varias soluciones para gestionar un caché o memoria intermedia en RAM, la más conocida posiblemente es memcached, y es la que más se ve en el mundo PHP. Otra de rápido crecimiento, también libre y de muy alto rendimiento es redis, que es la que vamos a usar en estos artículos. Es también la que está usando ahora mismo la página de Martianoids, este artículo se te está sirviendo desde un caché redis.

En esta serie de artículos vamos a ver como instalar redis, como administrarlo y utilizarlo desde Shell, PHP y Ruby, todos ellos en plano, sin frameworks, solamente para ver como funciona todo y que tengas una base desde la que empezar.

Instalación de Redis

Las notas de instalación son para Debian, pero servirán para cualquier otro GNU/Linux e incluso sabores de UNIX teniendo en cuenta las diferencias del gestor de paquetes.

Para instalarlo, accederemos como root y teclearemos:

root# apt-get update
root# apt-get install redis-server

Redis ya está funcionando. Comprobamos:

root# service redis-server status
redis-server is running

Administración de Redis

Para detenerlo, arrancarlo o reiniciarlo, utilizaremos los comandos típicos: service redis-server stop, service redis-server start y service redis-server restart.

Redis nos provee también de algunos ejecutables útiles para su administración:

El primero es para comprobaciones de rendimiento, escapa del alcance de este artículo pero es sencillo de probar, simula muchas conexiones simultáneas a redis y nos da unas estadísticas del tiempo que tarda en responder a diferentes operaciones. Lo podéis ejecutar sin ningún argumento o pedir la ayuda para tener una idea de las opciones de prueba: redis-benchmark --help.

El segundo y el tercero, redis-check-aof y redis-check-dump, sirven para comprobar la integridad de los volcados a disco que hace Redis y que veremos más adelante como se configuran.

El cuarto y más importante es redis-cli, un interfaz de consola. Con él podremos comunicarnos con el servidor y enviar todo tipo de comandos.

Por ejemplo para ver la configuración que tiene Redis en este momento entraremos en el cliente y teclearemos CONFIG GET *, así:

 root# redis-cli
 redis 127.0.0.1:6379> CONFIG GET *
  1) "dir"
  2) "/var/lib/redis"
  3) "dbfilename"
  4) "dump.rdb"
  5) "requirepass"
  6) (nil)
  7) "masterauth"
 8) (nil)
 9) "maxmemory"
10) "3758096384"
11) "maxmemory-policy"
12) "noeviction"
13) "maxmemory-samples"
14) "3"
15) "timeout"
16) "0"
17) "appendonly"
18) "no"
19) "no-appendfsync-on-rewrite"
20) "no"
21) "appendfsync"
22) "everysec"
23) "save"
24) "900 1 300 10 120 10000"
[...]

Otro comando muy interesante es MONITOR qué nos permitirá ver a tiempo real todas las operaciones que se están realizando en el caché:

 redis 127.0.0.1:6379> MONITOR
 OK
 1409486493.914086 "MONITOR"
 1409486523.671278 "set" "prueba" "1234"
 1409486528.015162 "get" "prueba"
 1409486599.506159 "get" "blog-post_cacheando-y-acelerando-con-redis-1"
 1409486599.506312 "get" "blog-page-max"
 1409486599.506453 "get" "blog-feed-atom"
 1409486599.506606 "del" "blog-feed-atom"
1409486599.506736 "get" "blog-feed-rss"
1409486599.506893 "del" "blog-feed-rss"
1409486599.507417 "get" "blog-page_1"
1409486599.507544 "get" "blog-page_2"

En la página de Redis hay un listado completo de comandos que podéis consultar para más información.

Fin de la primera parte

Esperamos que os vayáis haciendo a la idea de las posibilidades que tiene este fantástico caché. Hemos visto qué es, como instalarlo y en los siguientes capítulos aprenderemos a utilizarlo desde nuestros programas. No olvides visitarnos en un par de días si te has quedado con ganas de más, y recuerda que también puedes estar al tanto a través de:

• Feed RSS/Atom
• Twitter
• Facebook
• Google+

No te pierdas todas las partes de la serie sobre Redis: Parte I, Parte II, y Parte III.