The apache benchmark tool is very basic, and while it will give you a solid idea of some performance, it is a bad idea to only depend on it if you plan to have your site exposed to serious stress in production.
Having said that, here’s the most common and simplest parameters:
-c: (“Concurrency”). Indicates how many clients (people/users) will be hitting the site at the same time. While
ab runs, there will be
-c clients hitting the site. This is what actually decides the amount of stress your site will suffer during the benchmark.
-n: Indicates how many requests are going to be made. This just decides the length of the benchmark. A high
-n value with a
-c value that your server can support is a good idea to ensure that things don’t break under sustained stress: it’s not the same to support stress for 5 seconds than for 5 hours.
-k: This does the “KeepAlive” funcionality browsers do by nature. You don’t need to pass a value for
-k as it it “boolean” (meaning: it indicates that you desire for your test to use the Keep Alive header from HTTP and sustain the connection). Since browsers do this and you’re likely to want to simulate the stress and flow that your site will have from browsers, it is recommended you do a benchmark with this.
The final argument is simply the host. By default it will hit http:// protocol if you don’t specify it.
ab -k -c 350 -n 20000 example.com/
By issuing the command above, you will be hitting http://example.com/ with 350 simultaneous connections until 20 thousand requests are met. It will be done using the keep alive header.
After the process finishes the 20 thousand requests, you will receive feedback on stats. This will tell you how well the site performed under the stress you put it when using the parameters above.
For finding out how many people the site can handle at the same time, just see if the response times (means, min and max response times, failed requests, etc) are numbers your site can accept (different sites might desire different speeds). You can run the tool with different -c values until you hit the spot where you say “If I increase it, it starts to get failed requests and it breaks”.
Depending on your website, you will expect an average number of requests per minute. This varies so much, you won’t be able to simulate this with ab. However, think about it this way: If your average user will be hitting 5 requests per minute and the average response time that you find valid is 2 seconds, that means that 10 seconds out of a minute 1 user will be on requests, meaning only 1/6 of the time it will be hitting the site. This also means that if you have 6 users hitting the site with ab simultaneously, you are likely to have 36 users in simulation, even though your concurrency level (-c) is only 6.
This depends on the behavior you expect from your users using the site, but you can get it from “I expect my user to hit X requests per minute and I consider an average response time valid if it is 2 seconds”. Then just modify your -c level until you are hitting 2 seconds of average response time (but make sure the max response time and stddev is still valid) and see how big you can make -c.
I hope I explained this clear 🙂 Good luck