Apache Admin Notes: Raw Performance Numbers

In late Decem­ber I started look­ing at alter­na­tive web servers, hav­ing hit a point where I actu­ally asked aloud (though to no one in par­tic­u­lar) why I still use Apache for any http or php needs that may arise.

I sat down, installed nginx (nginx 0.6.33) from the EPEL (Extra Pack­ages for Enter­prise Linux) repos­i­to­ries and lighttpd (lighttpd 1.4.20) from the RPM­forge repos­i­to­ries (both third party repos­i­to­ries worth writ­ing about in detail at a later date). Apache was already installed (httpd 2.2.3), so a vir­tu­al­host was con­fig­ured to serve data from the same doc­root using all three servers, and PHP through fastcgi was con­fig­ured for lighttpd and nginx1.

I then set up a stock Word­Press 2.7 blog, some large images, some thumb­nails, and cre­ated what amount to approx­i­mately a 20k index page with noth­ing cached. Using ApacheBench to fetch 1000 requests, 100 requests at a time, I came up with some sim­ple num­bers show­ing how long it took to return the same page for each web server.

While I openly admit that the bench­marks pro­duced here are arbi­trary and super­fi­cial, they do give some rough insight (10,000ft overview level insight) as to how much faster nginx and fastcgi are over apache 2.2 and mod_php. lighttpd also per­formed admirably, and with less has­sle involved in set up than nginx, but I sus­pect that may just be pre­vi­ous famil­iar­ity with the configuration.

A table of num­bers (soon to be a graph, when I feel like mak­ing it) and some thoughts as to what they mean and why we (the web host­ing com­mu­nity) still use Apache reli­giously fol­lows after the jump.

Metric Apache ligHTTPD nginx
Time taken for tests
lower is better
45.584 seconds 24.199 seconds 17.395 seconds
Total trans­ferred
com­pres­sion was enabled
21691000 bytes 22059912 bytes 21894000 bytes
HTML trans­ferred
com­pres­sion was enabled
21464000 bytes 21833686 bytes 21671000 bytes
Mean Requests per second
higher is better
21.94 [#/sec] 41.32 [#/sec] 57.49 [#/sec]
Mean Time per request
lower is better
4558.396 [ms] 2419.853 [ms] 1739.542 [ms]
Mean Time per request
lower is better
45.584 [ms] 24.199 [ms] 17.395 [ms]
Trans­fer rate
higher is better
464.69 [Kbytes/sec] 890.26 [Kbytes/sec] 1229.11 [Kbytes/sec]

So what does all this mean? Well, the gist of it is that nginx is really, really god damned fast. Embar­rass­ingly fast. Note that I didn't say that Apache is slow. It's just not nearly as fast as nginx. How­ever, that being said, nginx is also not nearly as exten­si­ble as Apache is. The lack of sup­port for things that are taken for granted nowa­days (.htac­cess files come to mind) can be a stick­ing point for use in a shared host­ing envi­ron­ment. lighttpd doesn't sup­port most of those "expected" bells and whis­tles either, and an argu­ment could be made for such things being a waste of cycles… But the bot­tom line is that such bells and whis­tles are expected to work in a shared host­ing environment.

As for why the web host­ing com­mu­nity at large drops Apache into place when­ever we need an http server, I think it boils down to com­fort and lazi­ness. It's bun­dled with most linux dis­tros by default, we know it because it's been around for­ever, and its behav­ior is pre­dictable and famil­iar. It's become the Microsoft Office of http serv­ing, for bet­ter or for worse, and it's not going any­where any time soon. Even the 800lb gorilla behe­moth that is Microsoft IIS has failed to dethrone Apache for sheer ubiq­uity. I think the per­for­mance or secu­rity con­scious are always going to migrate towards some­thing with bet­ter speed and less attack vec­tors, but the typ­i­cal admin prob­a­bly just won't care.

And me? For now I'm going to con­tinue using Apache, while I work out if using nginx for any of the sites I host for peo­ple would be a prob­lem. If I can get the rewrite rules taken care of, and work out sim­ple site pro­vi­sion­ing, I might well make the switch. nginx seems like a no-brainer on sin­gle site vir­tual servers, where resources are scarce, and Apache isn't get­ting any more svelte these days.

--


  1. Credit where credit is due. I couldn't have started to work out the nginx fastcgi con­fig­u­ra­tion with­out help from this post on redemp­tion in a blog

No Comments