Persistencia en Redis

Problema

Al ser Redis un almacén de datos en memoria RAM, y ésta no es persistente, podemos perder datos en el caso de que haya un fallo. Si usamos Redis como cache, no debería ser un problema gigante ya que podemos recalentar la cache de nuevo y listos.

Casi seguro que tenga un impacto en rendimiento, los usuarios se tendrán que volver a loguear pero aparte de esto no habrá mas impacto.

Pero ¿y si queremos usar Redis de almacén persistente? ¿Es posible?

Sistemas de persistencia

Redis tiene varios modelos de persistencia, mediante los cuales guarda todo el contenido que tiene en memoria a disco. En el caso de error o reinicio de Redis, se leerían dichos ficheros para volver a dejar el nodo en el estado correcto. Tiene dos modos de operativa RDB y AOF.

Sigue leyendo Persistencia en Redis

Compresión GZIP y Redis

En mi antiguo trabajo hacíamos muchas peticiones a proveedores externos. De media eran unas 2K peticiones por segundo. Unos 170M peticiones al día. Cada una de éstas peticiones tenía su correspondiente respuesta, que acostumbraba a ser un JSON, pero podía ser un XML. El peso dependía mucho de la respuesta, pero variaba entre pocos KB hasta casi 1MB.

Guardábamos la respuesta en Redis, durante un breve periodo de tiempo (segundos). Al principio, guardábamos los datos «tal cual» y, obviamente, era un error.

GZIP

Comprimir texto es asquerosamente rápido. Hay muchos algoritmos de compresión, pero normalmente conseguiremos un 80% de compresión con respecto al tamaño original, y podemos comprimir entre 15 hasta 60MB/segundo.

En nuestro caso, no sólo era el tamaño en RAM que ocupaba éstos datos en el cluster de Redis, sino la transferencia de datos para guardar las claves en Redis, y leerlas seguidamente. Simplemente guardando información comprimida reducíamos dicho tráfico al 10-20% del original.

Sigue leyendo Compresión GZIP y Redis

Redis Benchmark

¿Cuán rápido puede Reddit Correr?

Redis es muy rápido, ¿pero cuánto? Realmente si no medimos la capacidad de nuestro nodo o cluster no podemos saber en qué cifras nos movemos y por tanto saber cuánto aguantará nuestra aplicación.

Pista: seguramente Redis no sea tu cuello de botella.

Velocidad de los comandos

En mi caso, desde un MacBook Pro (Retina, 15-inch, Mid 2015) con un 2,2 GHz Quad-Core Intel Core i7, y usando redis en Docker (redis:5) los resultados son los siguientes:

$ docker exec -it myredis redis-benchmark -q
PING_INLINE: 31847.13 requests per second
PING_BULK: 33411.29 requests per second
SET: 31377.47 requests per second
GET: 31816.74 requests per second
INCR: 31017.37 requests per second
LPUSH: 32520.32 requests per second
RPUSH: 30731.41 requests per second
LPOP: 32362.46 requests per second
RPOP: 33760.97 requests per second
SADD: 32499.19 requests per second
HSET: 32905.56 requests per second
SPOP: 32123.36 requests per second
LPUSH (needed to benchmark LRANGE): 31515.91 requests per second
LRANGE_100 (first 100 elements): 20942.41 requests per second
LRANGE_300 (first 300 elements): 12217.47 requests per second
LRANGE_500 (first 450 elements): 9434.85 requests per second
LRANGE_600 (first 600 elements): 7601.09 requests per second
MSET (10 keys): 29559.56 requests per second

En un servidor de DigitalOcean (Droplet 1GB) los resultados son:

Sigue leyendo Redis Benchmark

Traefik en Docker para múltiples entornos de devel

Traefik es un proxy HTTP, desarrollado en Go, OpenSource y que se lleva realmente bien con Docker.

La problematica es la siguiente: Si tienes diferents aplicaciones web en las que quieres desarrollar en local, lo normal es crear un Docker-Compose en cada una de ellas, tener un servidor HTTP como nginx o Apache corriendo, y, claro, lo normal es tenerlos escuchando en el puerto HTTP/HTTPS. Puerto 80 o 443, respectivamente.

Sigue leyendo Traefik en Docker para múltiples entornos de devel

Dockerfile y las capas AUFS o Overlay2

Cuando hacemos una build de una nueva imagen de Docker nos basamos en un Dockerfile, fichero que define exactamente los pasos a seguir para conseguir nuestra nueva imagen.

Una imagen de Docker está basada en diferentes «capas«. Digamos que con Docker siempre nos basamos en imagenes ya hechas, y descargadas de DockerHub. Éstas pueden ser imágenes de sistemas operativos como Debian o Ubuntu.

En este artículo explicaré como funciona el sistema de capas, que al principio es un poco confuso.

Sigue leyendo Dockerfile y las capas AUFS o Overlay2

Docker Vs Vagrant + VirtualBox para entornos de desarrollo

Cuando tenemos un entorno de desarrollo mínimamente complejo, necesitamos un sistema fácil, simple y fiable para gestionarlo.

Muchos habréis empezado a usar stacks LAMPP, XAMPP o el equivalente en otros lenguajes como Python o Ruby. Aún así, estos entornos se acaban quedando cortos a nivel de configuración y portabilidad.

Cuando el equipo crece, o si te cambias el PC tienes que reinstalar todo y configurar de nuevo. Suele llevar mucho tiempo.

Si vas a trabajar en diferentes proyectos que necesitan diferentes versiones de un lenguaje (Python 2.x Vs Python 3.x, o PHP5.X Vs PHP7.x), es un poco un infierno.

La solución siempre es la misma: virtualización.

Sigue leyendo Docker Vs Vagrant + VirtualBox para entornos de desarrollo