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.


Thu, 2010/02/04 - 15:45

glad you were able to speed up the site.

but i am not at all sure quicktabs should add caching. first, views has its own caching layer which is now relatively mature. second, most quicktabs implementations live in a block or could live in a block in some region. that means that block caching can b used to cache the whole HTML. I think of quicktabs as presentation stuff and I don't really think it is the right place for caching.

Thu, 2010/02/04 - 16:51

Blocks caching did not help here, because

a) the site uses a couple of node access module that prevents block caching from kicking in.

b) the quicktabs are not composed of regular blocks, but are made out of views (with block displays).

c) None of the quicktabs underlying views are affected by node access.

Views caching did not do anything for us, despite running the latest stable version (6.x-2.8). Perhaps this is because of (a) above.

Sun, 2010/02/07 - 02:06

Im using Boost, and the tabs load very fast.

But I dont know if it really cached by Boost or not.

Sun, 2010/02/07 - 10:14

It depends on what is in the tabs (heavy or not so heavy queries), and how Quicktabs is configured (load all tabs at once or load them when clicked).

If you don't see slowdowns, then don't apply the patch, since it will not help a lot.

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting