Directly after upgrading this weblog, little over a week ago, I felt it was a little bit sluggish. Compared to the 1.5 version I was running before. Maybe it could be just the webserver as I’m running on a shared hosting solution. Therefore one of the neighbours could be having a party… again. 🙁

But finding it slow on and off I decided to see how slow or fast WordPress 2.0 really is. This new incarnation of everyone’s favorite weblog tool supports ‘object caching’. Caching generally is a good thing. The results? Hmmm not good…

Test setup

For science sake, let’s pretend this is a wholy correct test in which all variables are controllable and repeatable. They were not. 😉 But then again, I just wanted to compare WP 1.5 to WP 2.0 and get an idea on how much of a hit I’m taking.

Testing was done locally on my iBook 12″, 1.33 GHz G4, 512MB running OS X 10.4.3 with Apache/1.3.33, PHP v5.0.4 and MySQL Standard 5.0.16. Note that the iBook is playing server and client at the same time. This will influence the statistics as it is not a dedicated webserver. Then again, a live webserver has lots of other things to do while serving my pages. Therefore I ran 5 different browsers (Safari 2.0, Firefox 1.5, Camino 1.0b2, OmniWeb 5.1.1 and Opera 8.51) to even out the results. Remember, I’m not looking for exact timings but average increase or decrease in serverload.

First I took a baseline with a standard, clean, new, installation of WordPress 1.5.2. Imported all the posts I had so far to fill the database and make it a more real environment. (Single post environments are damn fast! ;-)) WordPress offers statistics (do a view source and look at the bottom) so I noted those. This probably scews the results a bit, but it’s all I have.

After that I upgraded to WP 2.0 and increasingly added my custom theme and plugins. Meanwhile switching cache on and off. Again, I took notice of the provided timings by WordPress itself.

Results

Let’s cut things short. Here are the results:

* Delta is the percentual difference to the baseline. 100% means, twice as much as the baseline.
** Caching was enabled by default, but not working due to rights issues.

Conclusions

1. Just look at the baseline (scenario #1). OS X on an iBook… don’t make it a webserver! 😉 1,5 second for the homepage and half a second+ for a single post. For comparison, this webserver takes 0,353 seconds to build the homepage (with broken cache). But then again, it is a baseline to which to compare. (Note the ,=. notation in Europe)
2. If you want faster, go with WP 1.5.2 as any timing with WP 2.0 is slower. As you can see the number of database queries performed isn’t correlated with the time it took to construct the page.
3. Only after I disabled caching I found out the WordPress cache is broken!!! Compare scenario #2 with #4. It seems during the upgrade the wp-content/cache/ dir is appointed as disk-cache for commonly accessed objects (pages, categories, post-content, etc.). WordPress is happily trying to create a cache on every request by your visitors. Only to find out after many queries it isn’t allowed to cache it. You can check yourself by visiting you wp-content/cache/ dir. If it contains all sorts of files then it should be ok. If not, disable caching or CHMOD the /cache/ dir to 777, …
4. Even if you manage to make your WP 2.0 cache working. It sucks! Though this might be attributed to the OS X filesystem combined with local testing, there were less queries, but it took almost twice the time to construct a page. Again compare scenario #2 to #4. Just try and disable the cache to see how it works out in your situation… it might be worth it.
5. My custom ThinkLemon theme is slow for single posts. This isn’t a surprise as the default Kubrick theme shows only the post-content. My theme also shows categories and recent posts among other. No wonder it’s slower… (scenario #5)
6. When I enable all my ‘default’ plugins (recent comments, related articles, …) I get the biggest hit. Surely this doesn’t come as a surprise. Extra features mean extra time. But a double impact? (scenario #6) I think there definitely is some room for improvement here. Again see that caching enabled takes even more time… (scenario #7)

Wrapping it up. I’m not too happy with the new caching feature. Maybe I should just disable it. Then again, I really should take a look at my plugins, as they double the time to build a page. Probably the best is to take another look on the live server and find out where it hurts most.

I wonder what Matt’s thinking about his caching features…