WordPress, Web Servers, and Cacheing Plugin Testing

We run several high-traffic WordPress blogs on a lighttpd web server.  Combined, they get about 150,000 unique visitors per month.  We originally moved from an apache web server to lighttpd, because lighttpd can handle a much larger traffic load with the same server resources.

The problem with using lighttpd is that it is not very common for people to run WordPress on this web server.  Certain cacheing and mobile plugins need to alter the configuration of the web server.  Setup and debugging information almost always assumes an apache web server.  So in each case, we had to figure out a way to configure them for lighttpd.  When plugins get upgraded or go obsolete, we again have to find ways to get new plugins to work with lighttpd.  Over time, when we run into problems with our sites, we can’t rely on help being available on the web but have to figure it out ourselves.  Right now, for instance, we are noticing we have a memory leak somewhere which causes lighttpd to eventually fill up all available RAM and crash.

For this reason, we decided to do some performance testing on lighttpd vs. apache, as we were considering possibly going back to using apache.  While we were at it, we also decided to compare our current cacheing plugin, wp-super-cache and another leading plugin, w3-total-cache.

To do these tests we loaded up the latest copy of the Streetsblog.org code and data.  We used “ab”, the Apache HTTP server benchmarking tool to stress test the site from a separate machine.  Essentially, ab generates as many requests as we specify to the home page of streetsblog.org.  We ran each test three times and recorded the best result.  Before running each test, we would clear the cache on streetsblog.org.

Test Results

You can see the detailed results of our tests here.  For each of the tests, we recorded the connection times in milliseconds, the min, mean, median, and max, and also the number of requests a second handled by the web server.  The smaller the connection times, the better.  The more requests/second handled, the better.

Observations

From the results we drew the following observations:

For low server loads, apache is slower than lighttpd, but only by a small amount.  As we increase the load on the server, apache quickly balloons to max out the 4GB of memory on the server and crashes.  Lighttpd continues to scale to loads well beyond the load that apache failed at.  We tried installing fcgid mod and memcache modules on the apache web server and this seemed to give it slightly more capacity.

In almost all tests and ways of measuring, the wp-super-cache plugin performed better than the w3-total-cache plugin.  One thing worth noting, though, is that w3-total-cache minifies css and js files to speed up the experience for users but this operation wouldn’t be noticed by ab.  The performance between the two plugins is not that significant, however, compared with the savings they both provide over not having a cacheing plugin installed at all.

Further Study

It would be interesting to add more RAM to the server we are testing on to see how apache scales and compares with lighttpd at higher loads.

Thanks as to Evan and Myron for their assistance with this.

Comments are closed.