How to use the command 'ab' (with examples)

The Apache HTTP server benchmarking tool, commonly referred to as ab, is a powerful tool designed to test the performance of web servers. It simulates multiple concurrent requests to your server to evaluate its performance and identify potential bottlenecks. This tool is often utilized by web developers and system administrators to ensure that their web servers can handle a certain amount of traffic effectively. Below, you will find detailed examples of using the ab command to perform a variety of tasks, each tailored to assess specific aspects of your server’s performance.

Use case 1: Execute 100 HTTP GET requests to a given URL

Code:

ab -n 100 url

Motivation: This use case is essential for benchmarking a web server’s ability to handle a specific burst of traffic. By sending 100 GET requests, you can get a quick snapshot of how your server responds under a simplified load scenario, enabling you to gauge initial performance metrics like response times and throughput.

Explanation:

• -n 100: This option specifies the total number of requests to perform. Here, 100 requests will be executed.
• url: This is the URL to which those requests will be sent. It benchmarks the performance of the server hosting this URL.

Example Output:

Server Software:        Apache/2.4.41 (Ubuntu)
Document Path:          /
Document Length:        2345 bytes
Concurrency Level:      1
Time taken for tests:   0.561 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      245600 bytes
Requests per second:    178.25 [#/sec] (mean)
Time per request:       5.61 [ms] (mean)
Transfer rate:          423.44 [Kbytes/sec] received

Use case 2: Execute 100 HTTP GET requests, in concurrent batches of 10, to a URL

Code:

ab -n 100 -c 10 url

Motivation: This example is ideal for testing a server’s concurrency handling capability. Sending requests in batches of 10 simulates real-world scenarios where multiple users access the server simultaneously, testing its ability to handle concurrent connections efficiently.

Explanation:

• -n 100: Indicates the total number of requests to be performed.
• -c 10: Specifies the concurrency level, meaning 10 multiple requests are being made simultaneously.
• url: The specific endpoint being tested for performance under concurrent access.

Example Output:

Server Software:        Apache/2.4.41 (Ubuntu)
Document Path:          /
Document Length:        2345 bytes
Concurrency Level:      10
Time taken for tests:   0.391 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      245600 bytes
Requests per second:    255.75 [#/sec] (mean)
Time per request:       3.91 [ms] (mean)
Transfer rate:          584.94 [Kbytes/sec] received

Use case 3: Execute 100 HTTP POST requests to a URL, using a JSON payload from a file

Code:

ab -n 100 -T application/json -p path/to/file.json url

Motivation: This scenario is particularly useful for developers and testers who need to evaluate the POST method on web servers, especially when submitting data via JSON. Testing POST requests with a payload helps identify how well the server processes and responds to data submission, which is crucial for APIs.

Explanation:

• -n 100: Sets the total number of requests to perform.
• -T application/json: Sets the Content-Type header to application/json, indicating that the request body format is JSON.
• -p path/to/file.json: Specifies the path to the file containing the JSON payload to be included in the POST request.
• url: The endpoint for the POST requests.

Example Output:

Server Software:        Apache/2.4.41 (Ubuntu)
Document Path:          /
Document Length:        235 bytes
Concurrency Level:      1
Time taken for tests:   1.254 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      245600 bytes
Requests per second:    79.85 [#/sec] (mean)
Time per request:       12.54 [ms] (mean)
Transfer rate:          198.44 [Kbytes/sec] received

Use case 4: Use HTTP keep-Alive, i.e., perform multiple requests within one HTTP session

Code:

ab -k url

Motivation: Using the keep-alive option is advantageous for assessing how server performance is impacted when a single HTTP session is maintained for multiple requests. This is a common setting for modern web servers, intending to reduce latency by minimizing the number of TCP handshakes.

Explanation:

• -k: This option utilizes the HTTP keep-alive feature, maintaining the HTTP session for multiple requests.
• url: The target URL for multiple requests using a single session.

Example Output:

Server Software:        Apache/2.4.41 (Ubuntu)
Document Path:          /
Document Length:        2345 bytes
Concurrency Level:      1
Time taken for tests:   0.467 seconds
Complete requests:      50
Failed requests:        0
Keep-Alive requests:    100
Total transferred:      245600 bytes
Requests per second:    214.23 [#/sec] (mean)
Time per request:       4.67 [ms] (mean)
Transfer rate:          525.88 [Kbytes/sec] received

Use case 5: Set the maximum number of seconds (timeout) to spend for benchmarking (30 by default)

Code:

ab -t 60 url

Motivation: Testing with a time constraint is crucial for applications needing rigorous scheduling and performance checks. This allows developers to observe how many requests the server can handle within a specified time frame, reflecting both load endurance and efficiency.

Explanation:

• -t 60: Sets the time limit for the test to 60 seconds, meaning the benchmarking should end after this period, regardless of the number of requests performed.
• url: The specific URL being measured over the set period.

Example Output:

Server Software:        Apache/2.4.41 (Ubuntu)
Document Path:          /
Document Length:        2345 bytes
Concurrency Level:      1
Time taken for tests:   60.004 seconds
Complete requests:      6000
Failed requests:        0
Total transferred:      14560000 bytes
Requests per second:    100.00 [#/sec] (mean)
Time per request:       10.00 [ms] (mean)
Transfer rate:          235.88 [Kbytes/sec] received

Use case 6: Write the results to a CSV file

Code:

ab -e path/to/file.csv

Motivation: Exporting benchmark results to a CSV file facilitates the analysis and tracking of performance metrics over time. This practice is beneficial for reporting, monitoring historical data, and making informed decisions based on trends or irregularities in server performance.

Explanation:

• -e path/to/file.csv: Directs ab to write the benchmarking results into the specified CSV file path, providing a convenient format for further analysis or archiving.
• The command without additional options assumes defaults, so ensure the URL is implicitly specified or added if running a full test.

Example Output (CSV):

"Percentage served","Time in ms"
"50","3"
"66","4"
"75","4"
"80","5"
"90","7"
"95","9"
"98","10"
"99","11"

Conclusion

The ab command offers an extensive suite of options for testing and evaluating the performance of a web server. By understanding and utilizing these options, developers and system administrators can not only ensure their servers are configured for optimal performance but can also simulate real-world traffic scenarios, helping them preemptively troubleshoot potential issues before they impact end-users.