Tag Archives: Cache

The fastest caching combo for WordPress. Am I in a cached Nirvana?

Diagram of the basic operation of a cache
Image via Wikipedia

I hope you’ve recently noticed a significant improvement in the speed of the Division by Zer0.  I’ve done some further testing and I think I’ve discovered the perfect combination of tools which, at least for me, has made everything much snappier.

Last time I was playing around with Dreamhost’s FastCGI option1 as well as trying out a few newer caching plugins since Super Cache didn’t really play nice. Specifically I was testing Hyper Cache and DB Cache and trying to decide which one is better to keep. Well, in the end I figured out that using both is even better, and now I’m going to tell you why 🙂

Hyper Cache

This one is one serious mutha. It basically does the same thing as Super Cache but without requiring you to edit your .htaccess or other such hassle2. All you have to do is activate and go. And the results are really stunning. With it activated, I routinely get pages loading in sub-second speeds (whereas before the average was 2-6 seconds) on cached pages with very low overhead, which means I can withstand traffic spikes.

I was so impressed I spent an afternoon just reloading pages to admire how fast they loaded 🙂

Of course this plugin will not help with javascripts speed so if you have a lot of ’em, you will still notice your site taking a bit. However you should notice that the loading starts immediately and then waits for each javascript to download and run (so you’ll see the page appear in stages) instead of waiting a bit until it even starts loading (while it’s gathering prerunning the php and quering the DB). As such, if you have most of your javascripts loading at the footer (as you should), your content will appear immediately for your audience to start reading, and by the time they’re one the second sentence, the page will have finished.

My main problem was exactly that incidentally, that the content took up to 5 seconds to even appear. As long as the main text is there, I don’t mind so much how long it takes for the rest of the “bling” to load.

Another good thing about hyper cache is that it will not activate if you’re logged in to your wordpress installation. This means that in order to see the speed of your site as it appears to everyone else, you either need to use another browser (I keep a konqueror lying around just for this) or to clear your cookies. On the upside, it means that you almost always see the current version when you make non-content changes, such as editing your theme (as the cache will be automatically cleared if you make content changes.) This really helps if you like to tweak your site layout a lot.

One last (bad) thing I’ve noticed is that if I go ahead and clear all hyper cache. My site will die with an internal server error. I’ve tried this twice now. I do not know if that is because my site would die if hyper cache was not there or because once the cache is cleared, there some heavy duty function running to repopulate it or whatever. I know it happens though. I don’t have to do this anymore however so it’s not really a problem.

Overall, Hyper Cache is an absolute win for people hosting their own WordPress, especially if you’re on a shared hosting plan and even more especially if you’re using Dreamhost PS, as Super Cache is not an option.

DB Cache

This plugin takes a novel approach to caching. Whereas all the other that exist simply save the html output of your content and then serve it to avoid running PHP code each time a page is requested, DB Cache saves database query output to avoid making SQL calls to it.

This has a few significant benefits. First of all, it helps with Search Engine crawlers such as the google bot. Where a normal caching plugin really shines when a lot of people access one specific page, it actually harms you when one agent accesses a lot of pages, since you add the cache-saving to your load, on top of the normal page loading. DB cache on the other hand, by caching common Database queries, can fill exactly that hole which significantly reduces the juice you need to serve all the bots crawling you.

This is becauseeach page of your site, other than the main content and possible some post-related queries (ie similar posts), has basically the same calls. Your recent posts, your tag clouds and category lists, recent comments etc, depending on what widgets and theme you use. These generally don’t change from page to page but for a normal caching plugin on a new page, they still need to be called so that the full html page can be saved.

So by caching all these common calls, you seriously reduce the time one needs to wait on a blank screen before a page can even start loading the content. You also reduce the load when a crawler does his daily thing and you even increase the speed of the occasional visitor from a mobile. While DB cache will not give you the awesome speed hyper cache will on a single page load, it will certainly reduce your overall server’s CPU & RAM load (much more important than bandwidth and disk space for shared hosting) and make visits to uncommon pages quicker.

Another plus which I’ve discovered is when you are using Gallery2 through the wpg2 plugin. Gallery is imho a database chewer because people don’t simply see one image and then leave, but rather switch quickly among a lot of them. As a result, DB Cache is perfectly prepared to grab those common queries done through wpg2 and save them for later, increasing the overall speed.

The caching combo of ultimate speed

Until now I’ve never mixed caching plugins as they all generally worked in the same or similar way. However the distinct way these two worked gave me the impression that they wouldn’t really conflict and might actually complement each other quite well. One of them is built for serving one page to lost of visitors in a short time period, while the other is perfect for serving many pages to one visitor. So I went ahead and activated both of them at the same time

And whatdayaknow, there was no explosion 🙂

What happens at the moment is that generally, a page always has at least a few queries cached by DB Cache. You can even see the cached queries increasing with each time it’s reloaded (when bypassing hyper cache). This in turn allows a non-hypercached page to load quicker which is then saved into hyper cache for further visitors.

So currently you see the results of this experiment. I’d like to believe that my speed at the moment is quite good and others who have followed my advice have experienced similar improvements. I really hope this is the last time I have to play with caches in the future and that the current speeds are not just an illusion.

Let me know of the results if you try the same combo on your own sites.

Reblog this post [with Zemanta]
  1. Since disabled as it seemed to cause more problems than it solved []
  2. And removing it is simple too, unlike Super Cache []

Of WordPress Caches and Fast PHPs

Example of a Plug-In Framework
Image via Wikipedia

Improving the speed of this and my two other sites has always been a major issue for me. Ever since I’ve switched to WordPress I’ve never been fully satisfied with the loading time and it seems I’ve been trying since forever to improve it.  My main methods were through the use of caching plugins such a WP-Cache and later on WP-Supercache and through manual performance tweaking. For a while it seemed to have worked to a degree until again my performance started dropping without any apparent reason.

It was at this point that I jumped to the VPS offering in a desperate attempt to get a site which loads in this century. Again, for a while things looked to be working well but now and then I would get horrible site b0rks which would take me hours to troubleshoot and resolve. The latest one was the reason I discovered that WP-Supercache didn’t play nice with VPS and thus I had to find something else, or live with it in a state of half-on.

To my delight, it seems that now there are new caching plugins available which I can try. I already mentioned Hyper Cache last time and today I discovered DB Cache (h/t  diTii.com) which seems particularly promising, especially because it works not by caching the fully loaded page, but rather by caching the Database queries themselves. This is an interesting take on caching since it now can improve performance for web crawlers as well as normal users. It also provides an extra benefit to me since I’m proving a gallery through the wordpress interface, and that means that the database queries for that are also cached.

So I ditched Super Cache from all my blogs and installed DB Cache on the Division by Zer0 and the Wesnoth Journals and Hyper Cache on the ACP. It’s of course always difficult to figure out how much difference a caching plugin has done to your site. As of now, I can’t say I notice a significant difference on loading times with DB Cache, however I did notice that the number of SQL queries that are made each time the page loads have dropped from >60 to about 15 which means that there some difference.

I  have also noticed anotther thing. In the past it could take a few seconds before my site even started loading (I guess while it was running the SQL queries) but after that it would be displayed very quickly (especially if it had been supercached) whereas now, the site starts loading very quickly but it takes more time to actually finish loading the content, in effect loading in parts (first the header, then the content etc) but in a way that is much more exaggerated than before.

Another thing I also decided to do is to finally activate Fast CGI for PHP. I hadn’t done this before as it wouldn’t have made much difference when Supercache was in use but now that the code is executed every time, it seems like a good idea. There’s also the added bonus that for VPS, the Xcache opcoder is available which further improves php performance when on high load. I do not think it will make much of a difference as my problem is not one of traffic but it may come in handy for those rare reddit moments.

As of now, the performance seems comparable to SuperCache times and I am hoping that this time I will not have any more random Internal Server Errors. Unfortunately my WordPress admin panel is still quite slower than I’d like with loading times randing frmo 5 to 15 seconds or more on occasion. I honestly don’t know what I can do to fix that but at least the admin panel is not something that is used very often.

Next step will be to see if Hyper Cache is better than DB Cache and if they can both play well together for a combined improvement.

So what do you think of the current speed?

Reblog this post [with Zemanta]