Day 28: Write a High-Throughput Load-Testing Harness to Saturate the Server

Day 28: Write a High-Throughput Load-Testing Harness to Saturate the Server

In our last session, we used -XX:+PrintCompilation to observe how the JVM’s HotSpot compiler promotes bytecode to machine code. We saw the JIT compiler optimize hot paths in real-time. But optimization is a response to pressure. To trigger meaningful JIT activity and identify the true bottlenecks in AstraKV, we need to stop testing with manual curls and start subjecting the server to sustained, high-concurrency throughput.

Today, we build a dedicated load-testing harness. You will transition from "functional testing" (does it work?) to "load testing" (at what point does it fail?).

The Core Concept: Closed-Loop vs. Open-Loop Testing

Most engineers start by writing a loop that sends a request, waits for a response, and sends the next. This is a closed-loop system. It is fundamentally flawed for performance testing because the system inherently self-regulates: if the server gets slower, the client naturally sends fewer requests. It masks latency spikes and hides cascading failures.

To saturate AstraKV, we need an open-loop harness. An open-loop system injects load based on a predefined schedule (e.g., 5,000 requests per second), regardless of how the server is performing.

Real-World Stakes: The "Retry Storm"