What Is Load Testing? How to Test Your App Under Traffic

Your app works perfectly with 10 people using it. Then a marketing email goes out, a post goes viral or Black Friday arrives, and suddenly pages time out, checkouts fail and the database falls over. Nobody tested what happens when 2,000 people show up at once.

Load testing answers that question before your customers do. It simulates realistic traffic against your app so you can see how fast it responds, where it breaks and what to fix. This guide explains the main types of performance tests, how to run your first load test and how to read the results without a performance engineering background.

What load testing is

Load testing is a type of performance testing where you generate traffic against a system, usually many virtual users or requests per second, and measure how it behaves. The goal is to confirm that the app meets its performance targets at the traffic levels you expect.

A load test tells you:

• How quickly pages and API calls respond under normal and peak traffic
• How many requests fail as traffic rises
• Which part of the system becomes the bottleneck first: database, application servers, a third-party API or the network
• Whether autoscaling actually kicks in when it should
• How much infrastructure you need, which feeds directly into your cloud bill

Functional tests ask “does it work?” Load tests ask “does it still work when lots of people use it at the same time?”

Load, stress, spike and soak tests compared

“Load testing” is often used as an umbrella term. Grafana’s k6 documentation breaks performance tests into 6 common types:

k6’s guidance is to start with a smoke test, move to average-load tests and only then try more complex patterns. It also recommends simple shapes, such as ramp up, hold steady and ramp down, so results are easy to compare.

Which test should you run?

• Before a launch or big campaign: average-load test at expected traffic, then a stress test at 1.5 to 2 times that level for headroom.
• For flash sales, ticket drops or TV ads: spike test.
• For systems that run for days without restarts: soak test to catch memory leaks and connection pool exhaustion.
• For capacity planning: breakpoint test, run occasionally, to find your ceiling.

Most small teams get the biggest return from 2 tests: an average-load test and a stress test on their most important journeys.

How to run your first load test

1. Set clear targets. Write down what “good” means, for example: “95% of checkout requests respond in under 500 milliseconds at 200 requests per second, with an error rate under 1%.” Use your own business needs. Targets turn a load test from an experiment into a pass or fail check.

2. Pick realistic journeys. Use analytics to choose the flows that matter most and get the most traffic: home page, search, product page, login, add to cart, checkout, key API endpoints. Mix them in realistic proportions. Include think time between steps, because real users pause.

3. Use a production-like environment. AWS’s Well-Architected guidance recommends load testing in an environment that mirrors production as closely as possible, since a scaled-down copy can give misleading results. Use realistic data volumes, too. A database with 100 rows behaves very differently from one with 10 million.

4. Choose a tool. Common open source options include k6, Apache JMeter, Gatling and Locust. Cloud providers also offer managed load testing services. Note that protocol-level tools such as JMeter don’t run a real browser. Apache’s documentation states that JMeter does not execute the JavaScript in HTML pages, so it measures server and API performance rather than full page rendering.

5. Generate load from the right place. Run load generators outside the system under test, with enough capacity that they don’t become the bottleneck themselves.

6. Get permission and warn people. Tell your hosting provider and any third-party services you call, and follow their testing policies. AWS, for example, publishes a testing policy for simulated events, because heavy unannounced traffic can look like a denial-of-service attack. Never load test systems you don’t own or have permission to test.

7. Monitor everything during the test. Watch app servers, databases, caches and queues, not just the load tool’s numbers. Tracing tools built on OpenTelemetry help you see which service or query is slow.

How to read load test results

The numbers can look overwhelming. Focus on these.

Response time percentiles, not averages. Averages hide pain. Google’s Site Reliability Engineering book gives the example of a service with a 100 millisecond average where 1% of requests take 5 seconds. Look at:

• p50 (median): half of requests are faster than this
• p95: 95% are faster; this is a common target
• p99: the slow tail that your unluckiest users feel

Throughput. Requests or transactions per second the system handled. If you increase virtual users but throughput stops rising, you’ve hit a bottleneck.

Error rate. Failed requests, timeouts and wrong responses. Rising errors usually mean resources are exhausted somewhere.

Saturation. How “full” your most limited resource is: CPU, memory, database connections, disk or thread pools. The SRE book lists latency, traffic, errors and saturation as the 4 golden signals to watch on user-facing systems.

The shape over time.

Key takeaway: A load test is only useful if you know what “good” looks like before you start. Set percentile, throughput and error-rate targets first, then test against them and fix the biggest bottleneck before testing again.

Common bottlenecks and fixes

• Database queries: missing indexes, queries that return too much data or run in loops. Fixing these often gives the largest gains.
• No caching: repeated work for content that rarely changes.
• Connection limits: database or HTTP connection pools set too low, or too high for the database to handle.
• Third-party APIs: payment, email or AI services with their own rate limits. Check their limits and SLAs. Our guide to reading a cloud SLA helps.
• Autoscaling settings: scaling triggers that react too slowly for spikes.
• Architecture limits: some issues need deeper design changes, which our microservices vs monolith guide touches on.

Fix 1 bottleneck at a time and re-run the same test. Otherwise you won’t know what helped. Remember that more servers cost money, so weigh fixes against your cloud bill using FinOps practices.

Where to start: make load testing routine

1. Pick 3 critical journeys and script them in a load testing tool.
2. Run a smoke test, then an average-load test against a staging environment that mirrors production.
3. Set pass and fail thresholds for p95 response time and error rate.
4. Add a short load test to your pipeline for key endpoints, so performance regressions are caught like functional ones. See how to build a CI/CD pipeline and regression testing.
5. Run stress and spike tests before big events such as launches, sales and campaigns.
6. Schedule a soak test a few times a year, or after major infrastructure changes.

Add load testing to your pre-launch software QA checklist so it never gets skipped.

Conclusion

Load testing shows how your app behaves when real crowds arrive. Start with clear targets, script realistic journeys and test in a production-like environment. Use average-load and stress tests for most releases, spike tests for big events and soak tests for slow problems that appear over time. Read percentiles, throughput, errors and saturation together, fix the biggest bottleneck first and test again. A few hours of testing beats a launch day outage.

Sources

• Grafana k6 documentation: Load test types — smoke, average-load, stress, spike, soak and breakpoint tests and durations
• Google SRE book: Monitoring distributed systems — the 4 golden signals and why percentiles beat averages
• AWS Well-Architected: Load test your workload (PERF05-BP04) — production-like test environments and automated load tests
• Apache JMeter — protocol-level load testing and its JavaScript limitation