I started a war again the resource wasting on Periodo Fertile. That blog counts an important number of pageviews and even if the server has a lot of power it was suffering.
But that sound strange to me since with the same visitor load, months ago the server was not so overloaded. Why? WHY?
A number of plugins have been installed/update and the theme changed. Since I know how PHP coder work, I was suspecting under optimized code was raising the problem.
It is not Akismet, but while digging into the code, I found a little optimization for Akismet but the concept has general value.
Do not get_option() if the option it doesn’t exist
WordPress at startup loads all the options marked as “autoload”. It caches them and every call to get_option() is matched to the cached option names before try to read from the database.
But is an option is not present in the options table, it cannot be cache and the first get_option() call generates a query.
In Akismet you can find:
$akismet_comment_nonce_option = apply_filters( 'akismet_comment_nonce', get_option( 'akismet_comment_nonce' ) );
but the option “akismet_comment_nonce” is missing since there is not a place where to set it. Hence that generate a new query into the database on EVERY page load.
SELECT option_value FROM wp_options WHERE option_name = 'akismet_comment_nonce' LIMIT 1
If an option cannot be set form the administration panel we can assume it is false, so I temporary change the code to look like:
$akismet_comment_nonce_option = apply_filters( 'akismet_comment_nonce', false );
and asked for support to know if my assumption is correct. Maybe it is not, always ask the authors!
Conclusion
Always set your options as “autoload” if you need them on every page load, you’re saving a database query for each option not already loaded. Be sure all you options are present in the options table, specially when you add new options and the user does not save them from the administration panel. Update the new options into the database with default values.
In my case, another updated plugin added 10 new options and no one saved them on its administration panel. So every page load in the blog was running 10 useless queries, over the 100 query needed to generate the whole page.
