Key Takeaways
- Redis adds 40-128 bytes overhead per entry depending on data type
- Memory fragmentation typically adds 10-20% overhead
- Replication doubles or triples total memory requirements
- A 95% hit rate requires caching ~40-50% of your working set
- Redis can handle ~100k ops/sec per GB of memory
Comprehensive Guide to Cache Sizing
Effective cache sizing is crucial for application performance and cost optimization. An undersized cache leads to poor hit rates and increased database load, while an oversized cache wastes resources. This guide covers the principles of cache sizing, memory estimation, and optimization strategies for Redis, Memcached, and other caching solutions.
Understanding Cache Memory
Components of Cache Memory Usage
Total cache memory consists of several components:
- Key storage: Memory for storing cache keys
- Value storage: Memory for actual cached data
- Metadata overhead: Internal data structures, expiration info
- Memory fragmentation: Unused space due to allocation patterns
- Replication buffer: Memory for replica synchronization
Redis Memory Overhead
Redis adds overhead beyond raw data size:
| Data Type | Overhead per Entry | Notes |
|---|---|---|
| String | ~56 bytes | dictEntry + RedisObject + SDS |
| Hash (ziplist) | ~64 bytes | For small hashes (<512 entries) |
| Hash (hashtable) | ~168+ bytes | For larger hashes |
| List (quicklist) | ~40 bytes | Plus per-node overhead |
| Set (intset) | ~24 bytes | For integer-only sets |
| Set (hashtable) | ~64+ bytes | For string sets |
| Sorted Set | ~128+ bytes | Skiplist + hashtable |
Cache Hit Rate Mathematics
Working Set vs Cache Size
The relationship between cache size and hit rate follows a curve:
- Cache size = Working set size leads to near 100% hit rate
- Diminishing returns as cache size approaches working set
- Hot data follows power-law distribution (80/20 rule)
Estimating Required Cache Size
For a target hit rate, estimate cache size using:
- 90% hit rate: ~20-30% of working set
- 95% hit rate: ~40-50% of working set
- 99% hit rate: ~80-90% of working set
Eviction Policies
Common Eviction Strategies
| Policy | Description | Best For |
|---|---|---|
| LRU | Least Recently Used | General purpose caching |
| LFU | Least Frequently Used | Stable access patterns |
| TTL | Time-To-Live expiration | Time-sensitive data |
| Random | Random eviction | Simple, low overhead |
| volatile-lru | LRU among keys with TTL | Mixed persistent/cached data |
Redis Eviction Policies
- noeviction: Return errors when memory limit reached
- allkeys-lru: Evict any key using LRU
- allkeys-lfu: Evict any key using LFU
- volatile-lru: Evict keys with TTL using LRU
- volatile-lfu: Evict keys with TTL using LFU
- volatile-ttl: Evict keys closest to expiration
- volatile-random: Random eviction of keys with TTL
- allkeys-random: Random eviction of any key
Sizing for Different Use Cases
Session Storage
- Estimate: (Active users) x (Session size) x (1.5 overhead)
- Typical session: 1-10 KB
- Set TTL matching session timeout
- Consider sticky sessions vs distributed
API Response Caching
- Estimate: (Unique endpoints) x (Avg response size) x (Variations)
- Account for query parameter variations
- Consider cache-control headers
- Use cache keys that capture request uniqueness
Database Query Caching
- Estimate: (Unique queries) x (Result set size)
- Implement cache invalidation strategy
- Consider read-through vs cache-aside patterns
- Watch for cache stampede on expiration
High Availability Configurations
Redis Sentinel
- Automatic failover for single-master setups
- Memory: Master + Replica(s) + Sentinel overhead
- Minimum 3 Sentinel instances for quorum
Redis Cluster
- Horizontal scaling across multiple masters
- Data sharded across 16,384 hash slots
- Each master can have replicas
- Memory = (Data / Masters) x Replication factor
Managed Services
| Service | Provider | Notes |
|---|---|---|
| ElastiCache | AWS | Redis and Memcached |
| Cloud Memorystore | GCP | Redis and Memcached |
| Azure Cache | Azure | Redis only |
| Redis Cloud | Redis Labs | Multi-cloud, advanced features |
Memory Optimization Techniques
1. Use Appropriate Data Structures
- Hashes for object storage (more compact than strings)
- Packed encodings for small data (ziplist, intset)
- Avoid storing large blobs directly
2. Compress Values
- Use compression for values > 1KB
- LZ4 for speed, ZSTD for ratio
- Trade CPU for memory savings
3. Short Key Names
- Use abbreviated key prefixes
- Consider hash tags for cluster locality
- Balance readability with efficiency
4. Configure Memory Policies
- Set maxmemory appropriately
- Choose correct eviction policy
- Monitor memory fragmentation ratio
Monitoring and Tuning
Key Metrics
- used_memory: Total memory allocated
- used_memory_rss: Memory from OS perspective
- mem_fragmentation_ratio: RSS/used_memory
- keyspace_hits/misses: Hit rate calculation
- evicted_keys: Keys removed due to memory pressure
- connected_clients: Connection overhead
Warning Signs
- Hit rate dropping below target
- Evictions increasing rapidly
- Memory fragmentation > 1.5
- Latency spikes during eviction
Conclusion
Proper cache sizing requires understanding your data characteristics, access patterns, and performance requirements. Start with estimates based on your working set size and target hit rate, then monitor and adjust based on actual metrics. Remember that cache sizing is not a one-time exercise - as your application evolves, so should your cache configuration.
Use our calculator above to estimate your Redis or cache memory requirements and compare costs across managed service providers.