How to Make WordPress Run Faster
|October 16, 2010||Posted by Stephen Coursen under Web|
If you’re running a site that aims to be more than just a small journal or hub for your close friends to go to, you run into the problem of making sure that the site loads quickly and correctly for any visitor.
By “correctly”, I mean that it looks the same in all browsers. This is the easier of the two problems, since if you a platform such as WordPress, most of the available themes solve that problem for you.
Now, serving pages quickly can be tricky.
I ran several benchmarks over the last few days. I used ab (Apache benchmark) which is part of the standard distribution for the Apache web server. I ran it several times increasing the concurrency each time, to represent an increasingly heavy server load (such as would occur if one of your posts got on the front page of Digg, Reddit, or Slashdot).
(Note: for this post, when I use the phrase “WordPress server”, I am referring to an Apache installation running WordPress from one of its VirtualHosts.)
Originally, I had run my tests up to 100 concurrent connections. However, the default installation of WordPress on my server crapped out at 70 concurrent sessions, so I decided to only run the data up to 60 sessions. Each run of ab requested the front page of WordPress site 15,000 times, so the mean times should be meaningful since that data sample is — I think — large enough.
What we can see from the graph is that both the default WordPress install, as well as one using the WP-Cache plugin perform sluggishly across the spectrum. With a mean 6 requests/second, it’s not very inspiring. Especially considering that after 60 or so people hitting your server at the same it seems to grind everything to a halt.
It should be noted that WP-Cache seems to only effect browser caching (setting expire times and other headers), so so-called loyal visitors would not put such a high load on your server if they still have elements of your page in their browser cache.
I then turned WP-Cache off and installed the W3 Total Cache plugin. After configuring it with what I think are good settings for my server, I reran the ab tests.
What we can see from this graph is that adding in the PHP caching and database request caching abilities of W3 Total Cache allowed us to increase our server’s responsiveness to a mean of about 115 requests/second across the varying load. That’s roughly an increase of 20 times.
How does that happen? Well, it’s one of computer science’s principal adages: by increasing storage and memory consumption, you can increase speed and responsiveness. Think of it this way —
You talk to one your coworkers on the phone. During your conversation, you make some notes including some numbers and other figures that they gave you.
The next day, you need that information again because you need to write up a report. Since you took down the notes, you can quickly and easily get that information to reference for the report instead of having to dial up your coworker and fetch the information all over again.
Of course, the value of the information in your notes is only good for as long as it is correct. If anything significant has changed, your report will be useless since the cached data (your notes) you’re using is old. Ideally, your coworker would also tell you how long the numbers and figures are good for. When they’re past their expiration, you need to call up your coworker and request the latest values.
A lot of computer systems use this real-life concept. Web browsers can store copies of a web page for future reference, so they don’t need to re-download everything. W3 Total Cache employs a database cache, so that it doesn’t need to keep hitting the MySQL server and slowing everything down in the process.
Remember that a returning visitor that has parts of our site in their browser cache doesn’t need to re-fetch those items.
That’s a great thing, of course, but it only helps speed up that one browser’s visit. It doesn’t help at all if the person loading your page is new to your site and doesn’t have any part of it in their browser cache.
Of course, many companies and Internet service provides use proxy servers for Web access. Part of what a proxy server can do is cache frequently visited pages. This applies the same benefits of the local browser cache to all users of that proxy server.
What if your visitors don’t use a proxy cache? Is there anything we can do to help speed things up for them? A way to cache parts of our complex Web page, so that a new visitor doesn’t have to constantly hit the WordPress server for every bit of data?
The short answer is — yes, there’s something we can do. There are several “reverse proxy servers” available on the Internet, such as Squid or Varnish (I use Squid, so the rest of this post will be based on that). These programs sit in front of your WordPress site (or in front of any Web server). They forward requests to the server as needed, and they cache the results in memory and on disk.
When another request comes in for a page that Squid’s already forwarded, in can return the page in its cache instead of bothering the Web server with the request. (Not entirely true, it will often send a request asking the server if the request page has changed.) Squid can serve up its cached pages much, much quicker than the WordPress server can.
In the graph above, when we put Squid in front, the pages are process at about 1200 requests/second. Of course, I ran ab locally as that many concurrent requests would overload the bandwidth of my Internet connection.
But that’s a good problem to have. It’s much better to be bandwidth limited than to be running into the obstacle of an overloaded server. Increasing bandwidth to handle the spikes of a front page on Digg or Slashdot is much easier than having to build-out a server than can handle those spikes — most of the time, all that extra processing power would go to waste, where as there’s almost never such a thing as too much bandwidth.
Of course, putting Squid in front of your WordPress server only works if you have control over your server. In a shared hosting environment, you don’t have that control, so the best you can do is W3 Total Cache (maybe).
If you have a dedicated server or a VPS (Virtual Private Server), you can install and configure Squid to act as a reverse proxy for your website. If you find need help setting Squid up, you can contact me and I can help you get everything going.
What have you done to increase your server and site response times?