In process memory caching on the client side for redis

Having a process local cache could improve latency and reduce load on redis-cache because the client doesn't need to hit redis for each load from the cache. Since the first discussions in gitlab-org/gitlab-foss!30368 (closed) we are on Puma, which would make this cache more effecient since it would be shared across worker threads.

From the excellent discussion in gitlab-org/gitlab-foss!30368 (diffs, comment 189619471), there are some concerns about the effectiveness of this kind of cache.

Suggestions

1. A multi-level backend for Rails.cache

In gitlab-org/gitlab-foss!30368 (closed) there is a PoC for adding an in memory cache in front of Rails.cache using level2.

This would affect the majority of reads from our cache redis. Though some are implemented using Gitlab::Redis::Cache directly.

2. Using Redis 6 Tracking: Redis server-assisted client side caching

This would affect all of the uses of Gitlab::Redis::Cache without having to modify touch any application code. But it would require upgrading to Redis 6 and adding support for tracking to redis-rb.

?

Edited by Bob Van Landuyt