web developer & system programmer

coder . cl

ramblings and thoughts on programming...


comparing redis and memcached

published: 13-05-2011 / updated: 13-05-2011
posted in: development, programming, python, tips
by Daniel Molina Wegener

Key/Value and on-memory databases are widely used to store cached objects or documents. I am currently developing some Python/Django applications which are subject of strong data writing. For some tasks, I must choose between two Key/Value stores, and both are well known and widely used: redis and memcached. Instead of asking for benchmarks, I have prepared some simple tests to see which one will offer me the best performance in similar conditions.

The result is simple, I will choose redis instead of memcached, because redis I will allow me to have data persistence and its performance is very close and better than memcached. There are some advantages of redis over memcached, some low level considerations that are making redis the best choice for me. Both servers are using epoll_wait(2) calls, so they are using epoll family to wait for socket events on Linux, so, they developers seems to take care about performance. But the there are small differences between resource usage. While redis uses 2868KB on RAM and memcached uses 48048KB of it, with the same amount of data, both have the same performance, but memcached has a the higher cost.

With memcached I do not have persistence to store data on disk, and redis does async writes to the hard drive with custom rules to write data to disk when it is required, on server restart all the data on memcached can be lost, with redis and its persistence backend the data is restored. On sequential execution with reads and writes to the database, I have the following performance using Python as consumer:

Sequential Execution of Writes/Reads

Sequential Execution of Writes/Reads

But usually Web Application environments runs in parallel, so I have made some parallel tests over both engines. And the results are very similar.

Parallel Execution of Writes/Reads

Parallel Execution of Writes/Reads

And clearly the best options to store data into the Key/Value store is the cPickle module, instead of using JSON directly (with simplejson). If you will use the stored objects in your application logic, is better to have the cache using cPickle, and if you will use the stored object to be exposed to the browser in your Web Application, is better to have stored the simplejson object to expose them directly.

Both servers can use memory limits and seems that can use pthread limits too. Probably the difference is the fact that memcached is using complex concurrent programming techniques since it is using pthread_cond_wait(P) calls including pthread_mutex_lock(P) calls, and redis is only using at least pthread_mutex_lock(P). If that is true, probably the performance that can reach redis on heavy loads can be superior to the load that can have memcached, specially talking about small values. On the future, probably I will compare the hashing algorithm that is used to compare and store database keys and the concurrent write locking technique. Probably another disadvantage is the fact that memcached is using libevent as socket event abstraction layer, and redis is using plain calls, but finally both are using the epoll call family.

I will try to do more hard tests, mainly about the amount of data and key lookup, but for now everything seems to point to redis as best choice — despite how famous and used is memcached. Also, would be interesting to study if both databases are using its own allocator algorithm, and since they are using concurrent programming is more interesting to do some tests with lockless, jemalloc and the operating system provided memory allocator. Have fun caching your objects ;)


one comment to “comparing redis and memcached”

  1. [...] have compared redis and memcache with a lighweight test. Now I have compared both key/value stores with a harder test, using 100 [...]

post a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>