DB Cache is a new WordPress plugin that is aimed at increasing site performance by caching queries sent to the database.
The concept is great, however the WordPress blogs that will benefit from this plugin are of a very slim margin. Which is why I’m shocked its being rated so highly on WordPress.org.
A Common Complaint
The cause of this is because each query result is stored as a serialized chunk of data in a file. If you have an average blog (10-15 plugins installed) You’re probably pushing 40-60 queries per page (though it really depends what plugins). DB Cache seems to be able to cache about 95% of those 40-60 queries.
Each time an individual query is included back into the PHP script, it has to go through a process of checks:
- Checking to see if a file exists.
- Create a new one if not.
- Pull the existing one into place and unserialize the data so it can be used.
The flaw in this method of caching comes in the 3rd point (while reading the files). They can be just as expensive if not more expensive than most of the queries being sent to your database because each one is a separate request to the server.
By the time you open a file, read it, and then still have to run your code on the data provided… You might as well just used your database and had the results of your page fully up to date.
A simple SELECT statement is often quicker than sending another request to your server for a file. And, the majority of queries within the core of WordPress are not all that taxing to a database. For example, when you use something like blog_info() in your header template, it is doing a simple select on the options table.
A Use for DB Cache
DB Cache is still a useful concept, but one that I would only use if you maintain a site that has a lot of “expensive” queries. And by expensive I mean the ones that are doing multiple table JOINS, Lengthy WHERE’s and ORDERBY calls in their syntax.
How do you know if your site needs it? WP Pear Debug is a great debug tool for this. Use that to take a look at some of the queries being executed on your pages.
Another case in which it might help is if your database server and web server are separate. If your database is taking a pounding from other applications, using DB cache will take stress off of it and instead. Keep in mind, this is just transferring the workload to your local machine.
“Querying a database is probably going to be faster than looking for the same query in a filesystem manner. DB’s are optimized and efficent, filesystems have all sorts of caveats to cope with.”
An Additional Issue
If your site does warrant the use of DB cache from a couple expensive queries, your performance savings will probably just cancel out. Since a large portion of your queries are still going to be simplistic.
Ideally, this kind of caching is best ONLY on those expensive queries. If there was a way to specify what kind of queries were cached, this plugin would appeal to a lot more people. For now, It cant even help some of the more advanced WordPress development I work on.
Conclusions & Responses
I haven’t tested this to the extent that I’d like to. I also haven’t loaded this onto heavily trafficked site. If you test it on a site that receives a few thousand visitors a day, let us know your results. Maybe I’d be more willing to test it out in production on my sites if someone has positive results on a massive scale. Till then, super cache pulls a single cache of a page and still allows me to have dynamic output where I specify it.
If you comment on your test results please include how many plugin’s you are using and approximately how much traffic you receive daily.
Entrupeners, Subscribe for the lastest tools, tips, and tutorials.