Load Testing Plan

A load test that produces a pretty graph but no decision is wasted effort. The value comes from a plan: what question you are asking, which traffic you simulate, and what result would change your mind. This guide walks through building that plan and running tests that produce trustworthy numbers.

Learning goals

• State testable goals with pass and fail criteria
• Model realistic workloads from production data
• Prepare an environment and data that resemble production
• Report results in a way that leads to action

Step-by-step procedure

1. Write the question first, for example can the search API serve 300 requests per second with a 95th percentile latency under 400 milliseconds.
2. Define the test types you need: baseline, load at expected peak, stress beyond peak to find limits, and soak for several hours to expose leaks.
3. Build the workload model from production logs: request mix, think times, payload sizes and the ratio of reads to writes.
4. Prepare the environment. Match instance sizes, data volume and cache state, and isolate it from other users so noise does not distort results.
5. Seed test data with realistic cardinality. A table of ten rows behaves very differently from one with ten million.
6. Run a short smoke test, then ramp load in steps and hold each step long enough to stabilise, usually at least five minutes.
7. Watch the system, not only the client: CPU, memory, connection pools, queue depth and error codes.
8. Compare to the criteria, write the report, and repeat after each fix to confirm improvement.

Worked example

A team plans to test search ahead of a launch. Logs show 80 percent of requests are simple keyword queries, 15 percent use filters and 5 percent export results. They script that mix and ramp from 50 to 400 requests per second in steps of 50. Up to 250 requests per second latency stays flat. At 300 the 95th percentile climbs to 900 milliseconds, and database connections hit the pool limit of 100. The report states the finding plainly: the service meets the goal up to 250, fails at 300, and the cause is connection pool exhaustion. They raise the pool, add a query cache for filters, retest and reach 350 with latency under target. The launch proceeds with a clear scaling trigger at 280 requests per second.

Exercises and templates

• Write the goal, workload mix and pass criteria for one endpoint.
• Run a stepped ramp test and plot latency against throughput.
• List three ways your test environment differs from production and the effect of each.

Template:

import http from "k6/http";
export const options = {
  stages: [
    { duration: "5m", target: 100 },
    { duration: "5m", target: 200 },
    { duration: "5m", target: 300 },
  ],
  thresholds: { http_req_duration: ["p(95)<400"] },
};
export default function () {
  http.get("https://staging.example.com/search?q=widget");
}

Common pitfalls

• Testing from a laptop on a weak network, so the client becomes the bottleneck.
• Using the same few records for every request, which makes caches look better than they will in production.
• Running a single short test and generalising from it.
• Forgetting to test failure behaviour, such as what happens to latency when one node is removed mid test.

Follow-up and continuous improvement

Store test scripts and results in the repository, and run a small version in your pipeline before each release. Alert when latency under the standard test drifts more than ten percent from the baseline. That gives you an early warning of regressions long before real users feel them.

Adapting this to your team

Treat everything above as a starting point rather than a rulebook. Smaller teams can compress the sessions and merge roles, while larger organizations may need written templates, a shared calendar and a named owner for the practice. Begin with one pilot on a real project, collect honest feedback from participants, and adjust the format before you roll it out more widely. Consistency matters more than perfection, so favour a simple routine you will actually repeat.

Key takeaways

• Define success before running any test
• Workload realism matters more than raw volume
• Observe server side metrics to find the cause, not only the symptom
• Retest after every fix to prove the improvement