Redis
Your iOS backend is slower than it needs to be.
You’ve heard that adding a redis cache to your server can speed things up. But you don’t know what that is, or how much it will help, or how much it will cost, or how difficult all of that will be.
But there is one simple first question to answer that will take you more than halfway to your answer. It’s a math problem. An easy one.
We will get there in one minute.
But wait. What is Redis? How much will it help? Should I even be here reading this?
This post will be deliberately simple. I am going to tell you what redis is and help you answer the one question you need to ask to decide if you want to get more information. Then, in subsequent posts, we’ll provide more information.
Redis is an in-memory server side cache of your data.
Because Redis is an ‘in-memory’ cache, the information it contains can be access 5 orders of magnitude faster than data on disk. That’s 100,000 fold faster. Nice, eh? You’d store your whole database that way if you could afford it.
Because it is a server side cache, it’s not taking up memory on the iPhone. But that also means, it’s a cache that is available to all users of the service. And therefore, it works best if the data in the cache is something more than one user is interested in.
When your famously popular iOS dating app is downloading pictures for thousands of users, many of the users are downloading the same pictures. Most likely, they are downloading thumbnails of the primary picture of the other users who recently visited the app. That group of photos is being requested over and over. They are great candidates for a Redis cache.
On the other hand, when your enterprise medical app is in the hands of the health care provider at the hospital, and they are looking at the medical images or the patient portrait for today’s 2PM appointment, they are likely to represent the only request for that patient image today. Or perhaps they are one of two or four requests.
Now make the great leap to the mathematical generalization of when you need Redis. This is that one question I talked about. The question is whether your data requests follow a normal distribution, or if they follow a flat distribution. If they are flat, then all of your users are requesting different data every hour today and tomorrow and the next day. You won’t benefit from Redis. If on the other hand your data requests are following a normal distribution, then some of your requests, perhaps a large number of them, are for popular images on your dating app; or popular items in your shopping app. Other requests will be more unique.
The reason you will benefit comes from how Redis works. The Redis cache has to be populated in the first place.
• The user makes a request.
• The request first asks the Redis cache for the data. If this is the first request for the data, then the Redis cache doesn’t have the data, and the request is forwarded to the (slow) data on disk.
• As the resource is returned from the server, the data is NOW added to the Redis cache. And it is also retired to the user. But this is the first request. So it is slow.
• The second request is made. If your request distribution is flat, then the second request is likely to be for a new item, also not yet on the Redis cache. So again, the response time is dictated by the time it takes to read from the disk. If your subsequent requests are all unique, then you’ll keep getting the relatively slow response. And you’ll keep filling the Redis cache with information that no one cares about anymore.
• On the other hand! If your second request is for the same resource as the first request, then your data is quickly returned from the in memory store. If you have 10,000 users all wanting to look at the rumored images of the latest Apple Watch, and that single image is in the Redis cache, then they’ll all have a great user experience rapidly downloading the image.
• And if your app is one where users repeated look up some of the same items, over and over again, then your data requests follow a normal distribution. And you’re a great candidate for using a Redis cache.
Do you have a normal distribution of data requests? Lucky you!
Later.
