Why is :memory_store cache faster than :dalli_store for memcached? Should I just stick with :memory_store?

Question

Just starting to introduce caching into a new Rails app. We first set the cache_store to use :memory_store in the application.rb

config.cache_store = :memory_store

I then ran some performance tests through NewRelic to see performance before/after model caching occurred.

After that I switched the cache_store to use :dalli_store since it is the currently recommended gem to use memcached with Rails.

config.cache_store = :dalli_store

I then reran the same before/after caching tests against memcached. There was still an obvious improvement between the cached vs non-cached request/response; however the memcached cached performance was consistently twice as slow (roughly) as the standard Rails :memory_store.

Just for clarification, during these tests I ran the memcached server local to the rails web application so as to avoid adding network latency issues into the mix.

All of this leads me to the following real questions then.

1. Is it typical to see faster performance from :memory_store over :dalli_store?

2. If it is not typical, are there some 'tricks' I don't know besides the standard setup required to get proper performance from memcached?

3. If it is typical, then why people using memcached and :dalli_store on Rails in the first place? Is it a matter of scalibility, etc...?

Answer 1

From the rails caching guide regarding memory_store:

This cache store keeps entries in memory in the same Ruby process.

You'd expect that to be pretty damn quick for some benchmarks. It doesn't have to put any effort into reading to or writing from any other kind of storage. The cached stuff is just there when it needs it.

However, you can't store too much information like that before it becomes unwieldy. The processes for your server will grow and your cache will get rid of the oldest cached information pretty quickly (the default size of this cache is 32mb).

Also, with multiple processes running, as you'd have for a production server, you would be duplicating cached information across each process. For example, if your home page is cached you'd need to cache it on each of the processes that run on the server.

You're also going to have problems manually expiring things from a cache that is within the server processes because you need to either communicate with all the running processes to expire cached information or get them to check if the information is stale before accessing it.

By using something like memcached or redis you can have all of your server processes accessing the same cache and you can have a much bigger cache meaning that cached information becomes stale a lot less frequently. You can write once to the cache and all server processes benefit and you can clear once and all processes know it is cleared.

As you've identified, the trade-off is the performance of writing to and reading from the cache but on a system of any kind of size that performance trade-off isn't worth it compared to having a more sophisticated caching store.