This is the first part in a series of posts about Wordpress and performance. In part 1, we'll look at Wordpress in general, in later instalments, we'll look at how performance is affected by popular plugins and tweaks. (click here for part 2)
Wordpress is probably the most popular blogging platform out there today powering a countless number of blogs and other web sites. Wordpress was first released back in 200x and quickly became a popular tool for bloggers. Part of it's success is due to the fact that it's remarkably easy to install and configure. Another big hit with Wordpress is the community of users that contribute to the development by creating plugins. There are plugins for just about anything, display Google ads, search engine optimization, statistics, integration with social media just to name a few.
There are also downsides to Wordpress but the one that interests us the most is performance. Wordpress was once known to have lacklustre performance properties. It especially had big problems handling a lot of concurrent users. Imagine the disapointment from a young and aspiring blogger that writes endless amounts of excellent blogposts without being able to reach out to a bigger crowd. When he finally catches a break and gets that link from news.com, the Wordpress powered blog dies under the pressure and before the blog is back up again, that link from news.com is yesterdays news.
But Wordpress have gotten better. The default installation is faster out of the box and there are numerous of tips, tricks and guides on how to optimize Wordpress performance beyond what should be possible. And of course, there are also plugins that helps Wordpress to perform better. Our mission is to find out what the state of Wordpress performance is today. Let's start.
The tools we brought to the lab to do this series of tests are fairly simple. We have an out of the box Wordpress 2.8.6 blog installed on a single server. The server run Ubuntu Linux 9.04 on a Intel Quad Core 2.1 GHz machine with 8Gb RAM memory. The web server is the standard Apache2 that comes with Ubuntu and the database server is MySQL 5.1 located on the same machine. PHP is up to version 5.2.10. And the most important piece we brought was naturally a LoadImpact.com account to run the tests.
Establish a base line for the server
There are lot of moving parts in a setup like this. We first want to establish a baseline that tells us the maximum possible throughput on a PHP page in this specific setup. To do that, we created an simple php script that echoes exactly 10 bytes of data back to the browser. By load testing this simple script we get an understanding of how much of the page load time that is spent just on sending requests back and forth over the Internet, how well Apache2 can fire up the PHP processes and how much time PHP needs to initialize itself.
The baseline test and all the other tests we will be running is a ramp up from 50 up to 80 concurrent users. This is what the graph from the test look like:
As you can see. The response times actually gets better with more concurrent users (that's caching), overall it stays at or under 100 ms. So before putting Wordpress into the picture, we see response times at just under 100 ms. That's the best possible response time we could ever achieve with PHP at this load level on this particular server located at this particular IP.
Establish a baseline for Wordpress
Ok, next step is to see what we get when we install Wordpress. A standard Wordpress install will first and foremost run a whole lot more code than the previous script. It also connects to the database and looks for blog posts, comments and a lot of meta data such as what categories that are in use etc. So naturally we expect to see longer response times. We placed the same amount of load on the front page of the Wordpress installation as we did on empty.php, here's what an empty Wordpress blog looks like:
The response times now begins at just over 300 ms at 50 concurrent users and at 80 the response times are just over 350 ms. But that's not very interesting, we need to add a few posts so that the scripts and database gets some actual work done. Here's what the graph looks like when 10 posts are added to the blog:
That's a bit more interesting. We response times now starts at 425 ms, dips down to 364 ms at 60 concurrent users (mysql caching is our best guess here). At 70 and 80 concurrent users, the response times start rising quite sharply to 439 ms and 601 ms respectively. That actually starts looking like it's a "knee", the point where performance starts to really degrade and the server risks grinding to a halt. Let's see what happens if we add even more load:
Yes indeed. With more clients, the response times increases even more, as expected.
In absolute numbers, we're still talking about very good response times here even if this test is using a server with more CPU and RAM memory than the typical Wordpress installation have exclusive access to. And we are also looking at fairly high load levels. Getting 150 concurrent users on your blog is not going to happen to a lot of people and maintaining a reponse time of well under 2s is not bad at all.
The second thing to notice is that what we first suspected was a "knee" in the response time chart between 60 and 70 users does not look like a knee at all any more. The response times increases more or less proportionally to the load which is quite good. A really really high performing web site out there would display a more or less flat line for this load levels, but our setup is no where near that k
We've established a base line for Wordpress performance. We're going to keep testing this setup with various types of tweaks and write about it. The next part of this series will look at different plugins and how they affect performance, we've already tested a few of the most popular ones and some of them do affect performance quite a bit.
We want to know what you think. Are there any other specific plugins that you want to see tested? Should we focus on tests with more users, more posts in the blog, more comments? Please comment on this post and tell us.
(click here for part 2)