What is Load Testing?

What is load testing?

Load testing is the practice of simulating realistic user traffic against a website, API, or service and measuring how the system performs under that load. The goal is verification: you have a traffic forecast (Black Friday peak, a launch-day campaign, a daily 9 a.m. surge), and you want to know whether your infrastructure can handle it before real users do.

A load test typically ramps virtual users (VUs) up to a target concurrency, holds at that level for a sustained period, and records the metrics that matter: response times, throughput, error rate. If those metrics stay inside your performance budget (your service-level objectives, or SLOs), the test passes.

Why load testing matters

Without load testing, every release is a gamble. The first time you find out your checkout flow can't handle 5,000 concurrent shoppers is the moment your customers can't check out. Load testing converts that gamble into evidence.

Specifically, a load test answers:

• Will the system meet my SLOs at expected peak traffic? If your SLO is "p95 latency under 1 second" and the load test shows p95 climbing to 3 seconds at peak, you have a fix-or-postpone decision before the launch, not during.
• Where does latency start degrading? Response time usually scales linearly with concurrency up to a point, then climbs sharply. Knowing where that elbow is tells you your real capacity ceiling.
• What's the error rate at target load? A perfect-looking p95 is meaningless if 10% of requests are timing out. Error rate gates SLO compliance just as much as latency.

Load testing vs stress testing vs performance testing

These terms overlap and are often used interchangeably, but they answer different questions.

• Performance testing is the umbrella term for any test that measures non-functional system behaviour: speed, reliability, scalability under load.
• Load testing is a subset that focuses specifically on expected traffic levels. It's verification.
• Stress testing is the opposite of load testing: instead of running at expected load, you push past it to find the breaking point. It's discovery.

A typical engineering team runs load tests before every major release (CI/CD-friendly, fast) and stress tests less frequently (quarterly, or after architecture changes).

Key metrics in load testing

Five metrics matter most when reading a load test report:

1. Response time percentiles (p50, p95, p99). The average is misleading because outliers pull it around. p95 means "95% of requests were faster than this", which is a much better proxy for user experience.
2. Throughput (requests per second). How much work the system actually completes. Watch for the moment throughput stops scaling linearly with added load.
3. Error rate. Percentage of failed requests (HTTP 5xx, timeouts, assertion failures). Anything above ~0.5% under expected load is usually a fail.
4. Active virtual users. The concurrency the test is actually generating. Important to cross-check against your target, because many tools silently cap thread creation when local resources run out.
5. Resource utilisation on the system under test. CPU, memory, database connections, network. The load test shows the symptom (slow responses), but utilisation tells you the cause.

When to run a load test

• Before every major release. Wire load testing into CI/CD so each build is gated against your SLOs.
• Before a known peak. Pre-Black-Friday, pre-product-launch, pre-marketing-campaign.
• After infrastructure changes. New database, new caching layer, new region. Re-run the load test to confirm SLOs still hold.
• After significant code changes. Major refactors, framework upgrades, or dependency changes can shift performance characteristics subtly.

How load testing fits with stress, spike, and soak testing

Load testing is one of several "shapes" of non-functional testing:

• Load testing: sustained at expected peak.
• Stress testing: ramped past expected peak to find breaking point.
• Spike testing: instant jump from normal to peak (or beyond) to test elastic scaling and warm-up behaviour.
• Soak / endurance testing: sustained at moderate load for many hours to surface memory leaks and slow degradation.

The same scripts run all four. Only the load profile (thread group / scenario settings) changes.

Tools for load testing

The two open-source standards are:

• JMeter: Apache project, Java-based, GUI-driven. Strong protocol coverage (HTTP, JDBC, JMS, MQTT, gRPC), thousands of community plugins, the long-standing default in enterprise QA.
• k6: modern, code-first (JavaScript), built in Go. Lower memory footprint per VU, developer-friendly DX, integrates cleanly with CI/CD.

Both run locally for small tests. For realistic load (thousands of concurrent users from multiple geographic regions), you need a cloud runner. LoadFocus runs both JMeter and k6 from 25+ cloud regions with AI-powered analysis of the results.

If you'd rather not write the scripts yourself, LoadFocus offers load testing services where engineers write the scripts to your scenarios, run them at scale, and deliver the report.