Last updated on October 23rd, 2026 at 12:44 pm
ApacheBench can send a repeatable batch of requests to one URL. Start with a small run against a system you control, then increase concurrency only after checking errors and server load.
The example below is a diagnostic exercise, not a benchmark result. Replace the URL with a staging endpoint that represents the behavior you want to measure.
Start with one concurrent request
ab -n 50 -c 1 https://example.com/-n is the total number of requests. -c is the number sent concurrently. This first run helps confirm that the endpoint responds consistently before adding load.
Try a bounded concurrent run
ab -k -c 20 -n 250 https://example.com/This sends 250 requests with up to 20 concurrent requests and asks to reuse HTTP connections through keep-alive. Keep the trailing slash for a root URL. Run ab -V to record the tool version used for comparisons.
Read more than requests per second
- Check failed requests and non-success responses before comparing throughput.
- Inspect latency percentiles so slower responses are visible.
- Watch application errors, CPU, memory, and database activity during the run.
-
Repeat under comparable cache and traffic conditions, changing one factor at a time.
A fast redirect, challenge page, or cached error is not evidence that the intended application page is fast. Check the response separately before testing it. Variable response lengths can also be reported as failures; inspect the cause instead of hiding the signal.
Know the test boundary
A single-URL command does not simulate a full browser session, asset loading, JavaScript, or a realistic mix of users. A CDN cache hit measures a different path from an uncached request that reaches PHP and the database. Record which path you tested.
Use the result to compare a specific change under controlled conditions. Do not turn one short run into a claim about the maximum number of real users a service can support.
Reference: ApacheBench command reference.