I have put together several websites, and this consolidation involved moving 3 sites onto a server that already had 4 sites. All 7 are Drupal 6.
Last week I'd installed Block Cache Alter on another site (not one of those 7 and not run on the server in question), and seen performance improvement. The observation on that other site was to slightly improve CPU utilization, and somewhat decrease the memory requirement.
Last night I decided to install Block Cache Alter into all the sites now consolidated on the server. I finished that just before midnight last night, and just now looked at the Munin graphs and saw this dramatic result on MySQL. Additionally the memory allocation could be reduced back down to 1.5GB and CPU utilization is approximately the same as it was before.
What we see is a sharp decline in "update" and "insert" operations occurring just as I finished installing Block Cache Alter last night. Hence I feel safe in concluding this result came from installing Block Cache Alter.
Installing Block Cache Alter is straight-forward and doesn't involve anything strange like adding entries to settings.php (unlike Cache Router). However to have it give any affect you must edit all of your enabled blocks, and change the cache settings. It appears you don't have to alter cache settings on the non-enabled blocks.
There are a range of choices .. no caching, cache globally, cache per user, cache per role. It helps to understand the content of each block to know which setting to choose. Many blocks are static non-changing content and they would be fine to cache globally. Other blocks change their content depending on the logged-in user, or on the role of the user, or they change on every page view. Obviously if a specific block needs to change on every page view, it won't make sense to cache globally because it would only show the one cached value rather than the constantly changing value.
Here's how I configured the blocks:
- On one site I had several text-only blocks (hence, not changing) and decided to consolidate them all into one block, and set global caching on that consolidated block
- I found that most blocks could be set for global caching
- The "Navigation" menu is one that needs per-user caching, because its content changes based on the user ID.
- Some blocks have static text which contains javascript, and the javascript dynamically runs on page view in an AJAX fashion to display some data. Because the text Drupal stores doesn't change, it's okay to use global caching on those blocks.
- One of my blocks is a view that randomly selects on every page view 10 taxonomy terms from a large taxonomy. Obviously this one cannot be cached.
- The "Who's Online" block is another example of a block which cannot be cached.