How to make a Rails app faster with Redis
Why would I use it?
Redis is a performant key-value cache store. Its operations get done in mere microseconds. It can be installed and setup in the development environment in seconds, and it’s easy to manage standalone. It supports different types of keys and atomic operations, things that make translating business logic much easier, compared to something like memcache.
When would I use it?
Redis is really good for caching and doing on-the-fly operations with small to medium amounts of data. Think in the order of 1MB-1G.
When would I not use it?
Redis is not good when you have to do too much data transfer between single operations: think your Redis service will be most probably up in the cloud running on an unspecified physical server, while your application server most probably will be in a separate location. The network delay between requests to the Redis service will chew away at your performance gain. Another case is when you have to fire long operations:
Redis uses a mostly single threaded design. This means that a single process serves all the client requests, using a technique called multiplexing. This means that Redis can serve a single request in every given moment, so all the requests are served sequentially. This is very similar to how Node.js works as well.
If you have a long operation running, it will hold the queue of all of the other operations.
How would I use it?
Redis normally acts as a scratchpad or even as a queue, in fact Sidekiq uses Redis in the background for its jobs.
Think about a situation in which you would need it. Example: 20 most recent friend posts in the news feed. Every time a new post is added by a friend, push it to the list of posts and pop the oldest one. Retrieve the post list when you want to display it.
Another thing you have to decide is if you want to run a service on your own or use someone else’s, like Redis To Go. My experience with external providers is that you get around 100/200 requests per second, not more, especially if you start using types like Hash or Set. Based on their model, they share bandwidth and processors with other customers, which makes Redis re-initialize CPU registers like a headless chicken.
The situation improves 10x if you have your own service in AWS talking to your application server also in AWS (remember Heroku is AWS as well).
Performance improvements can also be gained by reusing connections with connection pooling, making less requests with pipelining and by using the hiredis-rb gem, which works with the raw format.
Gotchas?
Don’t use Redis as persistent storage for important data. In case of failure, it’s possible that not all of the data had already been persisted, as Redis runs persistency as a separate process.
This was just the tip of the iceberg. Learn the rest from Redis’ great documentation.
Did you like this?
If you liked this article, keep an eye my upcoming book about Rails 5 APIs. Register your interest here: http://goo.gl/forms/sOsrw5Ebcw
