Apache Bench (ab) Installation and Usage
Apache Bench is a single-threaded command-line computer program for measuring the performance of HTTP web servers. Its a standard tool often included with the Apache HTTP Server distribution.
Installation
On RHEL/CentOS-based systems, you can install the tool using the following package manager command:
sudo dnf install httpd-tools -y
Executing Tests
The syntax for running a benchmark involves specifying the number of concurrent connections and the total number of requests to perform. The command below initiates a test with 200 concurrent users sending a total of 10,000 requests to the target server.
# ab -n 10000 -c 200 http://192.168.1.50:8080/
This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.1.50 (be patient)......
Server Software:
Server Hostname: 192.168.1.50
Server Port: 8080
Document Path: /
Document Length: 321 bytes
Concurrency Level: 200
Time taken for tests: 1.835 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 5290000 bytes
HTML transferred: 3210000 bytes
Requests per second: 5449.32 [#/sec] (mean)
Time per request: 36.692 [ms] (mean)
Time per request: 0.183 [ms] (mean, across all concurrent requests)
Transfer rate: 2815.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.5 1 4
Processing: 8 35 6.2 34 55
Waiting: 8 35 6.2 34 55
Total: 8 36 6.2 35 56
Percentage of the requests served within a certain time (ms)
50% 35
66% 37
75% 38
80% 39
90% 43
95% 46
98% 50
99% 52
100% 56 (longest request)
Result Analysis
Throughput: The server handled approximately 5,449 requests per second. This metric demonstrates the server's capacity to process incoming traffic efficiently under the defined load.
Latency: The average response time per request was 36.7ms. The median (35ms) and the 90th percentile (43ms) suggest consistent performance with minimal deviation, though the longest request took 56ms, indicating a minor tail latency.
Concurrency: With 200 concurrent connections, the zero failure rate indicates that the server handles simultaneous connections robustly without dropping packets under this load level.
wrk: Modern HTTP Benchmarking Tool
Unlike Apache Bench, wrk utilizes multithreading to generate significant load. It is capable of sustaining a high throughput rate using event-driven I/O models similar to Nginx or Node.js.
Installation
Compilation from source is required for wrk. You will need development tools and OpenSSL libraries.
sudo yum groupinstall 'Development Tools' -y
sudo yum install openssl-devel git zlib-devel -y
git clone https://github.com/giltene/wrk2.git
cd wrk2
make
sudo cp wrk /usr/local/bin/
Executing Tests
This example runs a 10-second test using 8 threads and keeping 150 connections open. wrk is designed to push the server to its maximum capacity.
# wrk -t 8 -c 150 -d 10s http://192.168.1.50:8080/
Running 10s test @ http://192.168.1.50:8080/
8 threads and 150 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 8.45ms 3.12ms 45.20ms 72.15%
Req/Sec 2.25k 432.50 3.50k 68.44%
180456 requests in 10.05s, 87.86MB read
Requests/sec: 17955.22
Transfer/sec: 8.74MB
Result Analysis
Throughput: The tool generated roughly 17,955 requests per second, significantly higher than the ab test, reflecting wrk's efficiency in utilizing multiple threads.
Latency: The average latency remained low at 8.45ms. However, the standard deviation (3.12ms) and the maximum latency (45.20ms) suggest that while the average performance is excellent, there are sporadic spikes in response times.
Efficiency: The high "Requests/sec" per thread (approx 2.25k) indicates the client machine was not the bottleneck and effectively saturated the network interface.
wrk2: Constant Throughput Testing
wrk2 is a fork of wrk that adds a critical feature: the ability to maintain a constant request rate. This allows for testing scenarios where you need to verify server behavior at a specific load level rather than simply maximizing throughput.
Installation
As wrk2 is a modified version of the original, the installation process is identical, involving cloning the specific repository and compiling.
sudo yum groupinstall 'Development Tools' -y
sudo yum install openssl-devel git zlib-devel -y
git clone https://github.com/giltene/wrk2.git
cd wrk2
make
sudo cp wrk /usr/local/bin/
Executing Tests
The key parameter here is -R, which specifies the target throughput (requests per second). In this case, we strictly limit the load to 5,000 requests per second.
# wrk -t 8 -c 150 -d 10s -R 5000 http://192.168.1.50:8080/
Running 10s test @ http://192.168.1.50:8080/
8 threads and 150 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.12ms 1.05ms 12.40ms 60.22%
Req/Sec 625.00 50.12 800.00 35.10%
50012 requests in 10.00s, 24.35MB read
Requests/sec: 5001.20
Transfer/sec: 2.44MB
Result Analysis
Throughput Control: The server received exactly 5,001 requests per second, matching the -R 5000 parameter. This consistency is vital for SLA (Service Level Agreement) verification.
Latency Stability: Under a constant load, the average latency dropped to 5.12ms, and the maximum latency was significantly lower (12.40ms) compared to the saturation test in wrk. This indicates that while the server can handle bursts, it performs with more predictable latency at sustained, moderate rates.
System Health: The low standard deviation suggests that the server processing is stable when the request rate is controlled, providing a reliable baseline for performance tuning.