Web Server Load Testing: Tools and Methods

Intermediate

Load testing reveals your web server's true capacity before real users discover its limits. Without testing, you are guessing at capacity — and traffic spikes, marketing campaigns, or viral content expose those guesses as wrong. A systematic load testing process establishes baseline performance, identifies bottlenecks, validates optimization changes, and provides data for capacity planning.

This guide covers the most effective load testing tools, testing methodology, metric interpretation, and how to translate results into capacity planning decisions for both origin servers and CDN-fronted architectures.

What Are the Best Load Testing Tools?

How Do You Run a Basic Load Test?

# wrk: 4 threads, 400 connections, 30 seconds
wrk -t4 -c400 -d30s https://example.com/

# Output interpretation:
# Latency: avg 25ms, stdev 15ms, max 450ms
# Req/Sec: 12,500
# 375,000 requests in 30s, 1.2GB transferred
# Non-2xx: 0 (100% success)

# Apache Bench: 10,000 requests, 100 concurrent
ab -n 10000 -c 100 https://example.com/

# k6: Gradual ramp-up
# k6 run script.js
# script.js:
# import http from 'k6/http';
# export let options = {
#   stages: [
#     { duration: '30s', target: 50 },
#     { duration: '1m', target: 200 },
#     { duration: '30s', target: 500 },
#     { duration: '1m', target: 500 },
#     { duration: '30s', target: 0 },
#   ],
# };
# export default function () {
#   http.get('https://example.com/');
# }

What Methodology Should You Follow?

A proper load testing methodology avoids the common trap of running a single test and declaring victory:

1. Establish baseline — run a low-concurrency test (10 connections) to measure single-request latency and identify the server's raw response time without contention
2. Gradual ramp-up — increase concurrency in steps (50, 100, 200, 500, 1000), running each level for at least 60 seconds. Record throughput, latency percentiles, and error rates at each level
3. Find the breaking point — continue increasing until error rate exceeds 1% or latency exceeds acceptable thresholds. This is your server's maximum capacity
4. Optimize — apply Nginx tuning or Apache tuning changes based on bottleneck analysis
5. Retest — run the same test sequence after optimization to measure improvement
6. Document — record the test parameters, results, and server configuration for future reference

How Do You Interpret Load Test Results?

Throughput (RPS) is the primary capacity metric. Your server can reliably handle the RPS where throughput plateaus with acceptable latency and zero errors. Plan capacity at 70% of maximum to handle traffic spikes.

Latency percentiles matter more than averages. The p50 (median) shows typical user experience. The p95 shows the experience of the slowest 5% of users. The p99 shows the worst 1%. A server with 20ms average but 2000ms p99 has a serious tail latency problem that the average hides.

Error rate should be 0% under normal load. Any non-zero error rate under expected traffic indicates a configuration problem. Errors under peak load indicate capacity limits.

How Do You Test Through a CDN?

Testing through a CDN reveals different characteristics than direct origin testing:

1. Warm the cache first — send a single request to each URL to populate the CDN cache. Then test to measure CDN-served performance
2. Test cache-miss performance — use unique query strings (?bust=random) to force cache misses and test origin performance through the CDN
3. Test from multiple locations — use distributed load testing (k6 Cloud, Locust distributed mode) to test from multiple geographic locations simultaneously, simulating real global traffic
4. Monitor origin during CDN tests — check what percentage of requests actually reach the origin (CDN cache hit ratio) and the origin's response time for cache misses