Quicktabs can sure use more caching

For Drupal, Quicktabs is a useful module that provides helpful user navigation aids for a site. Used properly, it can be of great assistance to users navigating your site.

We mentioned in a previous article that certain settings can be detrimental to performance, for example, when you load all 3 tabs at once, in anticipation of the user navigating to them later. If the underlying blocks or views involve heavy queries, then the page loading can triple, and server load can suffer. We submitted a patch that warns the user that such a settings can have drawbacks. It has been accepted and is now part of the standard module.

We faced another case recently that involved quicktabs dragging performance down for a client site. They have several blocks that are visible on all pages, each with many tabs. All of those tabs were based on views, which were inherently heavy because of what they have to do.

Neither views caching nor Drupal core's block caching helped here.

The solution was to patch quicktabs to make it do its own caching of views. The patch is in the issue queue for quicktabs at
#342459, patch #54. There is a discussion about paging there, which does not affect our case, but others may want to chime in whether this is needed or not.

To assess the impact of with and without the patch scenarios, here are some pretty graphs:

The above graph shows the number of MySQL slow queries for that site after an upgrade for Quicktabs was applied without the patch and after the patch was applied. The slow queries are all views queries from quicktabs.

The aboev graph shows the number of MySQL threads going through the roof as well.

And this graph shows why the threads spiked: because there was so many PHP processes waiting to be served and MySQL could not cope up.

And no wonder the CPU usage was very high. The server was not happy.

Applying the patch made the site go back to normal again.