Skip to content
Home » Apache » Use Apachebench to test your webserver optimizations

Use Apachebench to test your webserver optimizations

If your web server is slow and you want to fix it, it’s nice to be able to quantify what you got. Enter Apachebench, which is part of Apache and probably already on your server.

The Apachebench caveat

Usage is tricky. The URL must end in a / or you’ll get an error saying “invalid URL.” I’ve warned you.

Ideally, run Apachebench beforehand, do your fixes, then run it again. Here’s the syntax I use:

ab -n 100 -c 10 http://localhost/

Apachebench results

Running it on my two servers, I found my new server is, in the worst case scenario, 21 times faster than my new one. Yes, twenty one. The new CPU and lots of memory helps, but some of that is the SSD, too. When both servers are at their best, the new one is 34 times faster. Still think SSDs are good at some things but bad at others?

In the real world, users won’t see all of that improvement because the Internet connection is a bottleneck. I ran the benchmark on the same machine, with no network at all. But with no network latency involved, the local machine can stress test itself much better than another machine can, so running Apachebench locally gives you a good indication of how the machine will handle the worst case scenario.

To test remotely, nothing stops you from running Apachebench from another computer, of course.

Other ideas

I threw a lot of hardware at my speed problem. There are other things I could do too, like switching to Nginx, and using the Dotdeb builds of the critical software like Apache or Nginx, MySQL and PHP instead of the official Debian builds. And if I really want to get wild and crazy, I can mess around with ramdisks. Yep, some high-traffic sites do that, too. If you want to know (and not just feel) what difference those other things make, benchmarking with Apachebench is the way to do it.

I’m at the point of diminishing returns, though. I got my big gain. In the coming days and weeks, I can throw some hardware in the old server, tinker on the old server behind the scenes, find better ways to do things, get some idea of the gains, and if and when I find something that looks like it will give me another jump in performance, make those changes on the production server.

If you found this post informative or helpful, please share it!
%d bloggers like this: