There’s been a lot made of Wordpress and its usage of the database - but I find that is always mainly limited to the frontend (the pages that normal readers see). What about the admin panel?

You’d think that it shouldn’t make much difference how many database queries the admin panel executes, because it’s only ever really used by a 1 or 2 people at most on a site. But I have found that one feature in particular can eat up your resources, especially if you are faced with a shared host that has a max_resources allowance (almost all do).

What is max_resources?

The max_resources (can also be termed as max_questions) kicks in when your database is used more than a certain number of times per hour. At the time of writing this for example, this blog’s current host will allow for 50,000 SELECT queries to be executed per hour, and 20,000 INSERT / UPDATE queries.

For most small sites, that’s actually quite a reasonable amount. Sometimes however, it can be consumed by some over-zealous code, that executes a lot of queries very quickly.

What to do about the error?

Look, it depends on how busy yout site is, but by and large you can minimise the frontend queries (generated by readers) with the use of the WP-Cache plugin. But that turned out to do no good in my case. I would still regularly reach my limit, even though there were very few database queries being executed by readers browsing the blog.

The problem turned out to be the autosave function! When you write a post in the post management page, if you are using WP 2.1 or greater, every so often you will see a message telling you the post has been saved. Every time the autosave fires however, it will use up queries in saving the data - and rather a lot of them too.

Not only was it using up a bunch of queries when saving, it was also executing plugins like the Google SiteMap creator. Now imagine leaving this page open for 30 minutes or more while you write the post, and you suddenly find you have reached your max_resources limit.

When it first started happening, I noticed it was almost always during or after the saving of a post. I first suspected a rogue plugin (Spam Karma was my initial guess), but then I thought of the autosave feature. I started logging all queries to a text file, and found that when I wasn’t on the post management screen, the blog was using up no more than a few hundred queries an hour, thanks to WP-Cache. When I left the page open at post management however, the log file grew in size so rapidly I knew it had to be the autosave.

Plugin to the Rescue:

I quickly made a small plugin to deal with the issue. There may be others out there that already do this, but I didn’t check (was quicker to write my own). All it does is change the frequency at which the autosave happens - setting it to a large number like 99999 seconds for example will effectively disable it completely.

You could always alter the timer to only occur say once every 10 minutes (600), or even longer. The default seemed to be too frequent for my blog, and I couldn’t find anything else that was causing such an error. I have yet to have the max_resources problem after making the change.

Download AutoSave Saviour

What about the rest of the admin panel?

Whilst the autosave function was definitely the main culprit, my log file did suggest some redundant / excessive queries were being used more generally. Take this example of a single load of post-new.php, at over 60 queries (most generated by lots of taxonomy related calls) .

I left a note in the support forum, detailing my concerns (who knows if anyone will ever see it!), so we shall see if they do anything about it. At the very least, there should be an admin option dealing with autosave. It is a useful feature, but maybe a little too intensive in its current state for some shared hosts.

I did upgrade this blog to the latest 2.4 dev code to see if anything had been done about it, but alas not so far.