El blog de Trespams

[ x ]

Faig servir les cookies de Google Analytics per al control de visites i estadístiques..
És una pardalada, però la llei diu que us he d'avisar, ja veus. Així que si visitau aquest blog donau-vos per informats o sortiu ara mateix i netejau les cookies del vostre navegador. Si continuau llegint, suposaré que ja us està bé. Si vols saber com llevar les cookies del teu navegador: aquí ho pots trobar

Redis vs Memcached

Com tots sabem si un vol que una aplicació web vagi ràpida hi ha un secret: posar en caché tot el que puguem. Evitar tenir que fer càlculs i anar a la base de dades a cercar la informació.

Per fer això l'estàndard avui en dia és Memcached. Memcached ens permet escalar la nostra aplicació d'una manera molt senzilla. És una gran taula hash, del tipus clau valor, escrita en C, molt ràpida i amb llibreries d'accés en pràcticament qualsevol llenguatge.

Però en els darrers temps ha sortit un nou competidor dins les bases de dades de tipus hash, aquest competidor reb el nom de Redis, i ja us n'he parlat quan tractàvem el tema de Celery.

Així com Memcached és una aplicació orientada a tractar amb caché, Redis és una base de dades noSQL de propòsit general, amb format clau-valor com Memcached, però amb unes possibilitats que van molt més enllà de un simple magatzem de memòria. Anem a veure un parell de diferències:

  • No podem veure les claus que tenim dins Memcached. Amb redis podem fer una cerca per claus, o veure-les totes amb la comanda KEYS *

  • Podem configurar Redis per a que sigui persistent.

  • Memcached està limitat a la memòria que li assignem, Redis pot utilitzar també el disc i sols posarà en memòria les claus.

  • Memcached no té una vertadera replicació, encara que podem fer que hi hagi molts servidors Memcached. Redis té replicació real i configurable amb una simple línia.

  • Redis és força configurable, podem definir el tamany de pàgina de caché, quant guardarem a disc, si volem tenir la base de dades protegida, ...

  • Amb Redis podem definir tantes bases de dades com vulguem. Podem netejar totes les claus d'una base de dades sense afectar a les altres.

Amb tot això és lògic demanar-se si enlloc de Memcached no podríem fer servir Redis per a les nostres aplicacions web. Si ho ajuntam amb Django tenim resolt un dels problemes més grans, que és la invalidació de cachés. Separant cada una de les nostres aplicacions dins una base de dades, podem fer un FLUSHDB a la base de dades de la nostra aplicació per invalidar la caché, amb la seguretat que no afectarà a la resta.

Però a la ciència les hipòtesis s'han de confirmar. Així que el que he fet ha estat muntar un petit entorn de proves per veure com se comporta una aplicació senzilla.

L'entorn de proves

El maquinar de que disposam per l'experiment és el següent:

  • Laptop Dell Core 2 a 2.16 GH i 2 Gb de RAM amb Ubuntu 11.04 Aquest servidor té l'aplicació web, i té l'adreça 192.168.1.35

  • Servidor virtual Ubuntu 10.04 amb 512 Mb de RAM damunt Virtualbox, executant-se damunt el servidor anterior amb l'adreça 192.168.1.38. Aquest servidor és de 32 bits i tindrà tant Redis com Memcached.

  • Apple PPC 64 Dual Core amb 3 Gb de RAM, ens servirà com a màquina per a llançar els tests.

L'aplicació és la que vaig fer servir pel creantbits (http://creantbits.com). És a dir, fa un accés a BD per obtenir els darrers esdeveniment i presenta la plana.

Utilitzarem dos workers de Gunicorn per iniciar l'aplicació, i la testejarem des de el PPC amb l'Apache Benchmark

ab -n 1000 -c 5 http://192.168.1.35:8000/

Per a cada test es llancen dos tests ab consecutius i es descarta el primer. Es repeteix 2 pics i es fa la mitja, arodonint cap avall en nombre de peticions per segon.

Per la caché de redis es fa servir l'aplicació django-redis-cache instal·lada des de PyPi.

Inici dels tests

Per començar hem de determinar el punt de partida. Així que el que farem serà desactivar la caché de la nostra aplicació i veure quantes peticions aconseguim.

no-cache    :   120 req/s    Mean: 41,4 ms

Activam la caché per site de Django i posam la caché a locmem. Locmem fa que la caché no pugui ser compartida entre processos i no és un opció recomanada per entorns de producció, però com abans, ens serveix per fixar el punt de partida:

locmem      :   1380 req/s  Mean: 3,6 ms

Posam la caché a memcached

memcached   :   626 req/s   Mean:   8,0 ms

Posam la caché a Redis configurada amb persistència a disc

Redis       :   623 req/s   Mean:   8.0 ms

Configuram Redis sense persistència. És l'equivalent a Memcached.

Redis       :   632 req/s   Mean:   7,8 ms

Utilitzam Redis amb el client hiredis

Redis       :   650 req/s   Mean:   7,7 ms

Conclusions

Crec que els resultats parlen per sí mateixos. Si volem persistència Redis és comparable en velocitat a Memcached, i a més pel mateix preu tenim una base de dades NoSQL en el nostre entorn i a la nostra disposició.

Si no volem persistència Redis supera per molt poc a Memcached i si aplicam totes les optimitzacions per tenir un entorn el més semblant possible a Memcached arribam a un 4% de millora. Aquest tant per cent no és significatiu, però si més no ens serveix per veure que Redis està al mateix nivell de rendiment que Memcached i ve amb tot el paquet d'opcions afegit.

Massa bo per no fer-ho servir!

blog comments powered by Disqus