- Published on
Replacing Redis
- Authors
- Name
- Alex Lee
- Title
- CEO
- @alexjoelee
Since our inception, we've used Redis as the in-memory cache for our edge servers. Today, we've replaced it with another solution entirely, and it's not what you think!
What is Redis?
Redis is a formerly open-source in-memory data structure store. Redis is fast and great for ephemeral data, like cache data. At Skip2, we run a Content Delivery Network which receives requests from the public internet and routes them to the web hosting provider. While we don't directly host any data, we do cache appropriate responses across our edge network. For this, we combined Souin cache module and Redis as the backend storage for it.
Issue 1: In-memory
In-memory is faster, yes. But, modern SSDs are also fast. When it comes down to it, we're talking about the difference between 1000 nanoseconds and ~500 microseconds, or 0.001ms and 0.5ms, respectively. A large gap, bit is this a noticable difference when we're talking about web applications? Weighing the current cost of RAM against this difference, we decided to primarily keep cache storage on SSDs now, instead of in RAM (though the cache key index is still stored in RAM).
Issue 2: Network Calls
Since we are running Redis as a separate service on our Edge Servers, each cache call initiates a new TCP connection between the web server and the Redis server. This means we have tens of thousands of connections looping back on the server itself. This increases server resource usage and latency to the cache storage. Keeping our cache on disk means we don't have to make any network calls - all the work happens inside the Souin cache module.
Issue 3: Empty Objects
A bug, or a circumstance of our deployment: Sometimes cached objects would be returned from Redis empty. Redis would be unaware that the object had been lost from memory, so the key would still appear valid but the data would be gone. This is fixable, but combined with the other issues, it is the final nail in the coffin for us and Redis.
Badger: Embeddable, persistent, and fast key-value (KV) storage
Written in pure Go, like the rest of our stack, Badger is the underlying database for Dgraph, a fast and distributed graph database.
Why Badger?
- It's designed for SSDs, which we use for all of our edge servers.
- It has the features we need (TTL support, is embeddable, high throughput)
- It tested great In our testing, it beat our Redis deployment every time. As soon as we deployed this globally, there was a noticable speed increase. This is directly due to Badger being embedded, and us being able to skip making an internal network call on every cache search.
Further optimization
Eventually, I envision that we'll add an additional cache storage into our network to improve read times for objects that aren't cached locally. But for now, with our current multi-tier caching strategy, performance and cache hit ratio have struck a nice balance.