Ja fa un bon grapat de setmanes que vaig comprar el Kindle DX d'Amazon. Vaig elegir el model gran, més pesat i no tan actualitzat com el model petit, ja que la meva intenció era fer servir el lector per llegir documents en PDF.

En aquest temps he pogut comparar amb amics la diferència entre llegir un Pdf a un lector petit o al DX i he de dir que estic content de la compra feta. Amb el DX no s'ha de fer cap tipus de conversió, les planes es llegeixen bé i no hi ha scroll vertical.

Això, però té un cost. El DX sols té connexió 3G i no WIFI, amb la qual cosa està limitat en la navegació que es pot fer. No pots anar més enllà de la Wikipèdia, ja que en intentar anar a altres planes et sortirà l'avís que la navegació està restringida.

L'altra emperò és que els llibres en Pdf no són navegables amb el cursor, això vol dir que no tens a l'abast el diccionari integrat, que va força bé quan llegeixes documentació, el diccionari no et dóna la traducció del terme, sinó la seva definició, amb la qual cosa tens moltes més possibilitats de recordar el terme per a la propera vegada.

He provat de comprar a Amazon i és veritat que és molt còmode, la compra és fa gairebé impulsiva. També hi ha un emperò, que en aquests moments els llibres tècnics tenen un preu a vegades superior als llibres en paper. Sols els salva que al manco els pots comprar sense problemes, cosa que no es pot dir de les llibreries que hi ha a les nostres contrades.

He comprat també a O'Reilly, aprofitant la seva política de promocions per Twitter. Tenen un format compatible amb Amazon i que no té DRM. El vaig provar comprant "Redis Cookbook" i funciona perfectament amb el diccionari integrat i tot.

L'altra cosa que he anat provant és la conversió d'algún pdf a format ebook amb Calibre, queda un format legible però en molts de casos el resultat no compensa l'esforç, encara és més còmode llegir-ho en el format pdf original.

En resum, el DX va molt bé pel que jo volia i les meves necessitats, però s'ha de tenir en compte que Amazon no l'ha actualitzat tan sovint com ha fet amb els dispositius petits, però per llegir documents en format A4 com els pdf va fantàstic, però si sols heu de llegir novel·les segurament el format normal de lector us resultarà més còmode i menys pesat (tant en pes com econòmicament).

With some help of our friend "Google Translate" :)

As we all know that if you want a web application goes faster there is a secret cache as much as you can. Avoid to generate the page each time and search for the content in the database.

To archieve this the today standard is Memcached. Memcached allows us to scale our application a simple way. We can think it as a big hash table, written in C, very fast and with libraries to access to it in almost any language. But thre is e a new competitor in this kind of applications: Redis, and I've already talked about it in the Celery post.

Memcached is an application aimed at dealing with cache, Redis is a noSQL general purpose key-value database in a similar way as Memcached, but with possibilities that go far beyond a cache. Let's see a few differences:

• We can not see the keys we have in Memcached. With Redis can do a search for keys, or see all the command KEYS *

• Redis has persitence.

• Memcached is limited to memory you allocate, Redis can also swapt to disk and just put the keys in memory.

• In Memcached we have no true replication. Redis replication is real and configurable with a simple line.

• Redis is quite configurable, we can define the page size of cache, store to disk, have a password protected database...

• With Redis we can define as many databases as you want. We can clean all the keys in a database without affecting the others.

So the next step is to ask if we could use Redis instead of Memcached for our web applications. Redis plus Django could partially solve one of the biggest problems we have: cache invalidation. As we can have an independent database for each application or for each purpose, we can FLUSHDB the database our application to invalidate the whole cache, or just delete the keys with a single Redis command.

But in Science hypotheses have to be confirmed. So what I did was to build a little sandbox application to see how if Redis was as good as it seems.

The Sandbox

The machines availables to us for the experiment follows:

• Dell Laptop Core 2 at 2:16 GH and 2 GB of RAM with Ubuntu 11:04 This is the Web application server and has the address 192.168.1.35

• Virtual Server Ubuntu 10.04 with 512 MB of RAM on Virtualbox running on the laptop at 192.168.1.38. This server is 32 bit and will host Redis as Memcached.

• Apple PPC 64 Dual Core with 3 GB of RAM, it will launch the tests.

The application is the one I created for creantbits. That is, to run it has to read BD for the last events and presents them in the page.

We will use two of Gunicorn workers to start the application, and we'll test the performance from the PPC with Apache Benchmark

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

For each test case two consecutive tests are thrown and we discarded the first.

To test the Redis cache we have installed the application django-redis-cache

The test

First we have to determine the starting point. So what we did is to clear our application's cache and see how many requests we get.

no-cache: 120 req / s Mean: 41.4 ms

We set up cache site for Django configured as locmem. Locmem is not recommended in production environments as it can't share the cache, but as before, we used to set the starting point:

locmem: 1380 req / s Mean: 3.6 ms

We configure the the cache as memcached

memcached: 626 req / s Mean: 8.0 ms

Cache Redis configured with persistence to disk

Redis: 623 req / s Mean: 8.0 ms

Cache Redis without persistence. Is the nearest Memcached equivalent.

Redis: 632 req / s Mean: 7.8 ms

We install the hiredis package

Redis: 650 req / s Mean: 7.7 ms

Conclusions

I think the results speak for themselves. If we use persistence Redis is comparable in speed to Memcached, and for the same price we have a NoSQL database at our disposal.

If we don't need persistence Redis shows a 4% improvement over Memcached. This percentage is not significative, but at least we can see that Redis is in the same leage as Memcached.

For me Redis it too good to not use it!

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!