Benchmarking and Load Testing Your Server: sysbench, ab, and wrk

Use sysbench to baseline CPU/memory/disk, then ab and wrk to load-test HTTP QPS and latency.

Before you go live, you need to know how much load your server can handle. This guide covers three staple tools: sysbench for hardware baselines, plus ab and wrk for load-testing HTTP services.

Installing the Tools

On Ubuntu/Debian:

sudo apt update
sudo apt install -y sysbench apache2-utils wrk

The apache2-utils package provides ab (Apache Bench).

sysbench: CPU, Memory, and Disk

CPU test (it computes primes — faster means a stronger core):

sysbench cpu --cpu-max-prime=20000 --threads=4 run

Higher events per second is better, and a lower total time is better.

Memory throughput:

sysbench memory --memory-block-size=1M --memory-total-size=10G run

Watch the MiB/sec under transferred. Disk I/O needs a prepare, run, and cleanup:

sysbench fileio --file-total-size=2G prepare
sysbench fileio --file-total-size=2G --file-test-mode=rndrw run
sysbench fileio --file-total-size=2G cleanup

Focus on read/write MiB/s and the 95th percentile latency.

ab and wrk: Load-Testing HTTP

ab is quick and simple. -n is total requests, -c is concurrency:

ab -n 10000 -c 100 http://your-server/api/health

wrk handles high concurrency better, with -t threads, -c connections, and -d duration:

wrk -t4 -c100 -d30s http://your-server/api/health

Reading the Numbers

  • Requests per second (QPS): how many requests are served each second — higher is better.
  • Latency: time per response. Lean on p95 and p99 (tail latency), not just the average — the mean hides stalls.
  • Failed / non-2xx responses: any non-200 means you are overloaded or erroring out, and that QPS figure is no longer trustworthy.

Load-Testing Do's and Don'ts

  • Never hit production. Test against a staging environment or a replica so you don't disrupt real users.
  • Ramp up gradually. Step concurrency from low to high (e.g. 10 → 50 → 100) and watch for where QPS stops climbing and latency spikes — that's your knee point.
  • Correlate with monitoring. While the test runs, watch top, htop, vmstat 1, and iostat -x 1 to see which layer — CPU, memory, disk, or network — is the bottleneck.
  • Drive load from another machine. Running the client on the same box as the service means they fight for resources and skew your results.

Summary

sysbench tells you what the hardware can do, while ab and wrk reveal the real throughput and latency of your service. The essentials: ramp up gradually, watch p95/p99 rather than averages, pair the run with system monitoring to find the bottleneck, and always validate in a test environment before touching production.