Pedal to the Drupal metal: Views Accelerator

×

Error message

  • Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in _menu_load_objects() (line 569 of /home/flinkco/public_html/includes/menu.inc).
  • Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /home/flinkco/public_html/includes/common.inc).

When caching is not an option, Drupal sites employing the Views module may find their performances bound by it. Getting to the bottom of this issue on a number of sites we discovered that performance benefits are to be gained in an unlikely corner of Views. We published a first version of the Views Accelerator module for everyone to reap those benefits. You’re invited to give it a burl. A couple of clicks on the UI could be all it takes to put a smile on the performance dial.

From simple to more complex analysis tools

Did you ever pay attention to that spinning circle while your browser is fetching your page? While that wheel turns anti-clockwise your browser is waiting for a reply from the server to your mouse click. Then as the server response streams in, the wheel reverses direction and the browser builds up your page. Details of each and every file processed during that phase and how long it took can be found under the Network tab of your browser console.
But when it comes to improving that left-churning part, no amount of browser analytics can help you. This is when you bring out the big guns. Like XHProf, or for D8, the Symfony-based WebProfilerBundle.
And you get ready to get your hands dirty, as you may have to dig deep.

When caching doesn’t cut it

But why take the trouble to analyse all this? Why not tell your customer to throw a pile of caching technologies at the under-performing site?
Because depending on the nature of your site, caching can be ineffective and even lead to functional errors.

The reason is personalisation/customisation.

Increasingly websites recall specific details about us to give us an enhanced browsing experience tailored to our preferences. Sites remember stuff we chose before. Brands, price ranges, travel destinations. Taking advantage of GPS/WiFi technology sites know where we are when we visit them. A map may place our current location at its centre and only show nearby points of interest — rather than the whole world.

Websites are moving from off-the-rack, one-size-fits-all to bespoke.

To cache is to assemble time-consuming pages once, to then dish out copies to everyone who ordered that same page. Caching does not cater for every guest bringing their own dietary requirements to the table. Personal preferences are indigestible to caching.

That’s when you have to take caching off the menu and look for alternative ways to speed up a site. So we cooked up Views Accelerator.

Identifying server-side slow spots

Tasked with making a customer site perform quicker we booted up XHProf. The culprit of slow performance was soon identified as a map featuring hundreds to thousands of nearby points of interest, centred on the visitor’s current location.

But it wasn’t any of the map engines or their APIs (Google, Openlayers, Leaflet) that were soaking up the seconds. Neither was it the database. It was Views. A little-known corner of Views.

Those familiar with the Views UI cockpit may know the tick box Show performance statistics on the admin/structure/views/settings page. With that checked, a preview prints out Query build time, Query execute time and View render time.

It’s like the developers of the Views module themselves felt those three numbers sum up all there is to Views performance.

But there is a fourth component… and it can slow your site down more than the other three together. XHProf proved it.

The performance opportunity

Between the query-execute and view-render phases, the code passes through a post-execute stage. This is where the raw results from the database are groomed for final rendering and theming. All results go through post-execute, even when this may not be necessary....

And with that we cue to the Views Accelerator project page. Featured there is a summary of a case study, proving how flicking on the module can boost Views speeds by 60%.

Views Accelerator is unconventional in its approach and is still in its infancy. Time will tell how the module matures in the community. We welcome feedback to help us improve the module.

Enable Views Accelerator on a test site. In Analysis mode it tells you how every view on every page you visit performs. Then in Accelerator mode it shows you those figures again. Hopefully the second time round those figures are a little leaner, making the user experience a little richer. If not, then your views may already be close to optimum. That is reassuring too, isn’t it?

So, no gain, no pain.... there is no reason not to give Views Accelerator a go.

Image taken from Time Magazine:
The $19 million Bloodhound SSC that is designed to shatter the world record on land with speeds over 1000 mph.


File under: 

Drupal 8: contrib roads, take me home

Read More »

Comments

It’s like the developers of the Views module themselves felt those three numbers sum up all there is to Views performance.
The timing statistics that Views give you date to early parts of Views, where post_execute() was mostly used by hooks that might change Views behavior. The heavier of post_execute() came because of field API in Drupal 7. Clearly, this is an oversight and the timers should include the post execute phase.

Thanks for confirming, MerlinOfChaos! I thought that might be the case. Still, the Field API in D7 has been around for a while now, silently adding its seconds. Unearthing the fact that the Field API can add a significant component to the timings certainly came as a surprise to me. RdeBoer

I have a module the replaces the entity load with a query for views https://www.drupal.org/sandbox/mikeytown2/2209909