Using redis to cache java objects: why it should be better than a ConcurrentHashMap?

Question

When profiling a java application currently under development at work, we have detected a few bottle necks that we can get rid of using caching. The application process requests and it should be as fast as possible doing so. We are considering Redis as cache solution because we already use it in the application. Basically we have to cache java objects. With Redis we have to serialize / deserialize those objects + network overhead. Given that basically Redis is a key value store, I was wondering if it may be more efficient to use a ConcurrentHashMap instead of Redis, as that will save us the serialization and network overhead. However, searching in the internet, I could not find anyone using it for this purpose. Am I missing something? Which is the practical limit of the ConcurrentHashMap for this purposes (in terms of concurrent requests and cached data volume)?

Answer 1

IMHO, ConcurrentHashMap is a suitable cache provided

• you don't need external access
• the total heap size is not too large e.g. 4 GB
• the level of concurrency is not more than about 20 CPUs (not just threads)
• it has the functionality you need.
• your expiry model is very simple.

Redis is designed to do much more than just cache values, and can be shared between processes using different languages, or even accessed via command line.