I wrote bsuite_speedcache to reduce the number of database queries I was executing per page load. By implementing it on some of the content in my sidebar, I dropped 35 queries for each cache hit. That might not seem like much, but it should average about 525 queries per minute that that my host server won’t need to process.
Now that I’m looking seriously at optimizing my queries, I’ve also cut the monthly archives links from the sidebar. The SELECT DISTINCT query it relies on hits MySQL hard. It wouldn’t be so bad if the get_archives function could be set to return the results (and my attempts at output buffering seemed to conflict with something else within WP), but it can’t and without being able to feed the results into the cache it has to be re-queried with every page load.
Between removing the archives links and bsuite_speedcache, I’ve gone from 136 to 99 queries for the front page and my story pages went from 65 to 28.
Where is it?
I’m going to ask my pal Zach (who knows a lot more about MySQL optimization than I do) to take a look at it with an eye toward making sure I’m not missing any easy optimization opportunities (and that I’m not causing trouble in one area I’ve got a question about).
With that done, and after I add some code to create the DB table and such, I’ll try to release it sometime this week.
tags: bsuite_speedcache, bsuite, cache, cache hit, codex, database, database caching, database optimization, database performance, database queries, mysql, mysql caching, mysql optimization, mysql performance, mysql queries, wordpress, wordpress optimization, wordpress performance, wordpress performance optimization, wordpress plugin