What is Load Testing? Definition and How It Works

What is load testing?

Load testing is a type of performance testing that applies a realistic, expected amount of traffic to a website, API or service and measures how it behaves. It answers one question: can the system meet its performance targets at the load we forecast? Virtual users ramp up to a target, hold there, and the test records response times, throughput and errors.

How a load test works

1. Set the target. Take it from analytics or a forecast: a launch campaign, a daily peak, a seasonal sale. Write down the pass criteria first, for example "p95 response time under 1 second and no failed checkouts".
2. Script realistic journeys. Real users browse, log in and buy, not just hit the home page. Mix the journeys in the proportions you see in production, with think time between steps.
3. Ramp up, hold, ramp down. Increase virtual users gradually to the target, hold long enough for the numbers to settle, then stop.
4. Compare against the criteria. Read percentiles, throughput and error rate, and look at CPU, memory and database metrics on the system under test to find the cause of any slowdown.

Example

An online shop expects a newsletter to bring 2,000 simultaneous visitors at 9 a.m. The team scripts browse, search and checkout, ramps to 2,000 virtual users over five minutes and holds for twenty. Throughput flattens and p95 latency jumps past the target at about 1,400 users, and the database connection pool is exhausted. They raise the pool, add an index and re-run until the target holds. (Numbers are illustrative.)

What to measure

• Response time percentiles (p50, p95, p99). Averages hide the slow tail that users actually feel.
• Throughput. Requests completed per second. Watch for the point where it stops growing as you add users.
• Error rate. A fast p95 means little if requests are failing or timing out.
• Concurrent virtual users. Confirm the tool really generated the load you asked for.
• Server resources. CPU, memory, connections and queues explain the symptoms.

Common mistakes

• Testing only the home page. The slow part is usually search, checkout or an API behind login.
• Skipping think time. Users that never pause are far more aggressive than real ones and give a misleading answer.
• Generating load from one machine or region. The generator becomes the bottleneck, and you miss network effects.
• Testing a tiny staging copy. Results only transfer if the environment and data volume resemble production.
• Running it once before launch. Performance drifts with every release; run it regularly or in CI.

Load testing and its neighbours

Load testing checks behaviour at expected traffic. Stress testing pushes past it to find the breaking point, spike testing jumps suddenly to peak, and soak testing runs for hours to expose leaks; capacity testing and scalability testing ask how much load the system can carry and how it grows with resources. For the practical differences, read load testing vs stress testing and the guide to endurance and soak testing. A load test run after each release also works as regression testing for performance. Load tests run before users arrive; monitoring watches the live system afterwards.

Tools and where to go next

The common open-source engines are Apache JMeter and Grafana k6. LoadFocus load testing is the product page for running JMeter and k6 tests from 25 cloud regions in the browser, with live results, pass/fail thresholds on p95, p99, error rate and throughput, and AI analysis of finished runs. The free plan allows up to 10 virtual users. To plan realistic scenarios, see how to design load testing scenarios.

FAQ: load testing

What is the difference between load testing and performance testing?

Performance testing is the umbrella term for measuring speed, stability and scalability. Load testing is one type of it, focused on expected traffic.

What is the difference between load testing and stress testing?

A load test runs at the traffic you expect and checks you meet your targets. A stress test goes beyond that to find where and how the system fails.

How many virtual users should I test with?

Derive it from real data: peak concurrent users from analytics or a forecast, plus headroom for growth. Do not pick a round number.

When should I run a load test?

Before a launch or known peak, after infrastructure or major code changes, and regularly in CI so regressions show up early.

Can I load test in production?

It is possible but risky. Most teams test a production-like environment, and only test production carefully, with a plan to stop and with the business informed.

Which tool should I use?

JMeter suits teams with existing .jmx plans and broad protocol needs. k6 suits teams that prefer scripts in JavaScript and CI workflows. A cloud runner is needed once you want thousands of users from several regions.