Performance Regression: Significant Redis Hit Rate Drop and CPU Spikes after Implementation

[Aqours]

After migrating to nextjs-cache-handler with a Redis backend, we observed a significant regression in cache efficiency and resource utilization:

1. Cache Hit Rate: Dropped from >90% (previous implementation) to approximately 60%.
2. CPU Usage: Average CPU usage increased by 5%-10%, accompanied by frequent CPU spikes (spiky behavior) in our Kubernetes pods.

Environment Details

• Next.js Version: 15.3.8
• Cache Handler Version: 2.5.3
• Deployment: Kubernetes (K8s)

Questions & Potential Issues

1. Root Cause of Hit Rate Drop
We noticed a sharp decline in the Redis hit rate. Is this expected due to the way cache-handler manages tags or metadata? Are there specific "auxiliary" queries (like tag validation) that might be inflating the "Total Gets" and lowering the overall hit percentage?

2. CPU Spikes & Resource Overhead
Our pods are experiencing 5-10% higher CPU load with visible spikes. Could this be related to:

• High frequency of serialization/deserialization?
• Intensive Redis SCAN operations or tag-matching logic?
• Lock contention during cache revalidation?

3. Integrated In-Memory (L1) Cache Support
We are looking for a hybrid caching strategy similar to nextjs-turbo-redis-cache that utilizes a local In-Memory L1 cache to shield Redis and reduce CPU overhead from network I/O and serialization.

• Does nextjs-cache-handler support a built-in "Local Memory + Redis" multi-tier strategy out of the box?
• If so, what is the recommended configuration to ensure L1 hits reduce the CPU load on the main thread?

[AyronK]

1. Root Cause of Hit Rate Drop

Not exactly "inflating Total Gets" in the sense of fake misses, but this implementation does several Redis commands per successful cache read, and some paths turn a string GET into an effective miss. Your observability may label things differently than "one GET = one cache lookup."

• Dashboard hit rates for GET alone are not comparable: each lookup can add HEXISTS + HMGET, and UNLINK on invalidation paths.
• More implicit/soft tags → larger HMGET.
• A drop from >90% to ~60% is not “expected by design” as a fixed number, but semantics differ from a naive handler: stricter invalidation and metadata can increase real misses and change how metrics count operations.
• We had a similar issue before in Fix: Race condition #192, which I believe has been fixed, perhaps look at the PR for reference.

2. CPU Spikes & Resource Overhead

Serialization / deserialization
Every get/set (de)serializes the full stored value, this will affect CPU if you relied on in-memory cache previously.

Redis scanning / tag work
Scanning hashmaps containing tags for revalidateTag etc. is expensive and can affect CPU, especially if you relied on in-memory before.

Lock contention during cache revalidation?
I am not aware of any implicit locks in this package 🤔 Is there anything in particular you're referring to or is it a guess?

3. Integrated In-Memory (L1) Cache Support

You can use local-lru cache handler. The multi-tier strategy is not supported out of the box, but the pieces are there. You may need to implement your own strategy that combines it into a layered system. You can take composite handler as an example, it's rather meant to mimic a strategy to pick either redis or in-memory. I am sure it shouldn't be much effort to implement a Handler that combines lru and redis to first use lru with shorter expiration time and redis as second layer.