๐ Bottleneck Hunting ยท Days 19โ24
Day 23: Caching Effects
Objective
Test cold vs warm cache; then bust the cache mid-test.
Scenario
First run: hit an endpoint repeatedly - notice response time drops (warm cache). Second run: send unique requests each time - cold cache. Third: evict cache mid-test and watch the cliff.
Metrics to Watch
When It Clicks
Performance is a cliff - it falls off the moment the cache misses.
Solution
Run 1: Flush the cache (Redis FLUSHDB or app restart), then run 100 unique-URL requests. Capture p95. Run 2: Repeat the exact same 100 URLs in the same order. Capture p95 - this is the warm-cache baseline, often 5-50x faster. Run 3: Mid-test, flush the cache with a script or CLI command. Watch the Response Time Graph for the cliff. To instrument cache hits: add a custom response header in your app (e.g. X-Cache: HIT/MISS) and use a JMeter Response Assertion or extractor to count the ratio.
Reflection
How much faster was the warm cache? What percentage of your production traffic is cacheable?
Deliverable
A cache-effect comparison script with cold/warm/bust variants.
โ ๏ธ Never run load tests against infrastructure you do not own or have explicit written permission to test. Always use a dedicated test environment. Unauthorized load injection can cause outages, trigger legal liability, and violate terms of service.