Choosing the Right Load Testing Tool: ab, wrk, and Locust Compared

Load‑Testing Overview

Before a service is released it should be verified that it can sustain the expected traffic. For an estimate of 1 million API calls per day concentrated between 08:00 and 20:00, the average request‑per‑second (RPS) is roughly 22. Because real traffic spikes 3–5× the average, a target RPS of 66 – 110+ is recommended for a safe launch.

ApacheBench (ab)

ab is a classic command‑line load‑testing tool. A typical invocation is: ab -k -c 100 -t 10 http://domain/path Parameters: -c – number of concurrent requests (concurrency). -t – total test duration in seconds. -k – adds Connection: Keep‑Alive header, keeping HTTP/1.0 connections open, which reduces dynamic‑port exhaustion and increases pressure on the target.

wrk

wrk extends ab with multithreading, allowing full utilization of multi‑core CPUs. A basic command is: wrk -c 100 -d 10 http://domain/path Key options: -c – concurrency. -d – duration (e.g., 10s). -t – number of threads (default 2; increase for more cores).

wrk uses HTTP/1.1 with keep‑alive enabled by default, so there is no -k flag. To force short‑lived connections you can send an explicit header:

wrk -H "Connection: Close" -c 100 -d 10 http://domain/path

wrk also supports custom Lua scripts for complex request logic, though script development is more involved.

Locust

Locust differs from ab and wrk by allowing user‑defined scenarios that can involve multiple, inter‑related URLs. It runs in a distributed mode, so you can simulate thousands of concurrent users and obtain results that resemble real‑world traffic patterns.

For full usage details see the official documentation: http://docs.locust.io/en/latest/

Other Tools

Beyond ab, wrk, and Locust, tools such as GoReplay and TcpCopy can replay live production traffic to a test server, providing highly realistic load. These utilities require more elaborate setup and are suited for cases where exact traffic patterns must be reproduced.

Best Practices for Load Testing

Run the load‑testing client on a separate machine in the same LAN as the target server. Do not execute the client on the server under test, otherwise the client’s own resource consumption will bias the results.

If long‑lived connections are used, monitor the TCP TIME_WAIT state. On Linux you may need to adjust kernel parameters, e.g.:

sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_tw_recycle=1

Apply only when the network environment permits.

Continuously observe system bottlenecks: CPU utilization, disk I/O, and network bandwidth. If none of these resources are saturated yet the measured RPS plateaus, investigate the load‑testing tool’s configuration (e.g., thread count, connection limits) or off‑CPU time spent in the client.