Planning a Performance Test Before a Major Release

“Run a load test before launch” is a common request, but without a clear question the result is a graph nobody knows how to read. A useful performance test starts with a decision the business needs to make.

Define what “fast enough” means

Agree on measurable targets before writing a single script. Good targets name a percentile, an operation and a load level:

95% of checkout requests complete in under 800 ms at 300 concurrent users, with an error rate below 0.5%.

Averages hide pain. Use percentiles (p95, p99) so that the slowest experiences are visible.

Model realistic load

Look at production analytics or logs to find out what users actually do and in what proportions. A realistic mix — for example 70% browsing, 20% searching and 10% checking out — is far more valuable than hammering a single endpoint.

• Include think time between steps.
• Use varied, realistic test data to avoid unrealistic cache hits.
• Ramp up gradually instead of starting at peak.

Choose the right test types

• Load test — expected peak traffic; does the system meet its targets?
• Stress test — beyond peak; where does it break, and does it recover?
• Soak test — normal load for hours; do memory leaks or connection exhaustion appear?
• Spike test — sudden bursts, such as a campaign email going out.

A small k6 example that encodes the target directly as a pass/fail threshold:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '5m', target: 300 },
    { duration: '20m', target: 300 },
    { duration: '5m', target: 0 },
  ],
  thresholds: {
    'http_req_duration{name:checkout}': ['p(95)<800'],
    http_req_failed: ['rate<0.005'],
  },
};

export default function () {
  http.get(__ENV.BASE_URL + '/products');
  sleep(2);
  http.post(__ENV.BASE_URL + '/checkout', JSON.stringify({ sku: 'SKU-1001' }), {
    headers: { 'Content-Type': 'application/json' },
    tags: { name: 'checkout' },
  });
  sleep(3);
}

Prepare the environment and data

Results only transfer to production if the environment resembles it: similar instance sizes, the same configuration, realistic data volumes and the same third-party limits (or stubs that behave like them). Warn every team that shares the environment before you start.

Run, observe and compare to a baseline

Client-side numbers tell you that something is slow; server metrics tell you why. Watch CPU, memory, database connections, slow queries and queue depth during the run. Keep each run’s results so the next release can be compared against a known baseline.

Report in business terms

Finish with a short summary that answers the original question: targets met or not, the capacity limit found, the bottleneck identified, and a recommendation. Detailed graphs belong in an appendix, not on the first page.