Wordpress Processor Load
Revised: April 19, 2007
While photogabble has never had the burden of being dugg, let alone slashdotted I still like to keep my server in top condition for that just incase moment where I suddenly get a lot of traffic. It only occurred to me that I hadn’t reviewed this issue for a while and it was looking like my Wordpress install has become slightly bloated with plugins I don’t use and code which could be edited out. So with a fresh install of Wordpress I shall work on making it stand up to any amount of traffic.
I must first before I begin share with you the basic statistics of my server. It’s an old 1.5Ghz P4 system, it used to be an office box and so only came to me with 256MB of RAM. The server is hoasted on a 1Mbit upload 2Mbit download DSL line although those speeds aren’t sustainable and tend to flux a bit although all in all I feel it’s a well enough set up for what I do and people have surivived getting dugg with a lot less than this.
To begin I searched google and quickly found several blog posts about how people had gone about preparing their websites against excessive traffic that digging and slashdotting provides. However a lot of them focused on the time it took for a page to load and mysql queries. I feel that these are a little shallow to be considering as they don’t actually address the issues in hand; server load and processor usage. With these in mind I opened up a shell to my server and used the Linux command top to provide me with a real time feed of server load and processor use. I could also using this, find out which processes where using server resources on page load. I loaded a couple of pages on my website and watched the statistics jump about, what I found is a little suprising. When each page loads I would expect to see that the mysql daemon hammers the server and considering that my Wordpress install hits the database with 48 queries on the index page alone that’s not too bad an expectation. Unlikely as it sounds its the opposite that happens! As a benchmark when called, the index page puts an average load of 32% on my servers processor while loading an directory index causes a load of 2 to 12%. What is suprising about loading the Wordpress index page is that the vast majority of processor usage is handled by the apache2 daemon while the mysql daemon uses 2% or less!
This vast difference can only be put down to the fact that my mysql installation uses caching regularly while apache has to call up a dynamic page every time which causes it to have to run php code thus burning up system resources - 32% of system resources to be exact. All this talk of percentages is confusing however when put alongside the server load average. Loading of a directory index page doesn’t change the load average one bit, while loading the Wordpress index causes a load average of: 0.08 0.02 0.01. Therefore as focus of this investigation I am not going to focus on load averages and rather processor usage and page load times.
MySQL Persistent Connections with WordPress
Ryan on his blog speaks about the mysql_pconnect function, and how this can reduce the load on the server. The simple tweak took all of two minnutes to impliment however the improvements where vastly noticable with server load reducing down to an average of 22% used by apache2 while mysql used 0.3%. Just two minutes of editing and I have already reduced the processor usage by a third, I can’t say however that the page load time is noticably quicker but I shall attend to that issue with my next modification. Firstly I must say however that persistent connections do have a draw back and that is simply that they use up more system memory as php keeps open a range of connections to the database for future use. This however shouldn’t be too much of a worry as the load advantage in this case is worth a little bit of memory hogging.
WP-cache
I never before thought about installing somthing like this, the idea that the content which my visitors would be viewing isn’t live troubled me slightly as I update my blog several times a day and like to think that as soon as I press publish it’s live. A silly notion I’m sure, but it did worry me none the less. After reading Brandon Harper’s article on Surviving A Slashdotting With a Celeron 466 and reading about wordpress optimisation on openswitch.org I was inspired to give this plugin a go because other than reducing the number of content based plugins I use there is very little else I can do to minimise the amount that apahce2 hits the mysql database. The benifit of this plugin is that it entirely removes the mysql interaction with the page for as long as you wish the page to be cached for. I chose a safe time of ten minutes however if one where to get dugg then a cache timeout of an hour or so would more likely be advisable as then the advantage would be felt for longer instead of ten minutes of low load and then a minute of high load as the page is cached again with no change. It would be nice to see how it handles new post and comments, and wether it updates the cache when they are created.
Before WP-cache was installed and run my Dynamic pages where served in about 1.4 seconds and caused an average load of 22% on my server. After being cached using WP-cache processor load was suprisingly reduced to 13% Yes that is a total reduction of 9% on the persistent connections mod, and an amazing total reduction of 19% since the benchmark.
I am impressed that spending just half an hour modifying wordpress has given me an almost 60% improvement in server resource use. I know that with such a small blog as mine and reasonably low viewer traffic I am unlikely to ever amass anything like a digg or slashdot article and thus the 60% improvement will be hardly noticable. However when you tesselate that improvement to a server that has a sudden traffic spike, 60% can mean the difference between the server dieing and the website staying live.
Now that I have guarded my website against traffic spikes (not that any are expected any time soon) I need to modify the plugin so that the rating plugin is dynamic on the page. There is plenty of documentation on how to do this, so I shan’t go into detail here unless asked. However I hope that this article was of some use to someone and that if it was then could you leave a comment or at the very least rate this page. Thanks 
