This project is not covered by Drupal’s security advisory policy.
For those not reading the full project page or the README: this module improves speed by rendering Views fields simpler and more efficiently. If you find that after turning the accelerator on for a view, fields don't render quite as expected and the tips in the README don't help, then you should switch the accelerator off for that view.
Views Accelerator can bring about significant speed improvements on sites with views that cannot be cached normally, for instance because the views depend on an aspect of the visitor's session, like their location.
Views Accelerator serves up two modes of operation.
- Analysis mode:
Switched on from the module's configuration page, admin/config/system/views-accelerator, this displays at the top of the screen a performance summary for each view on the page. If performance is already great, tell your boss or customer. If it isn't, take a screenshot of the performance summary and proceed with the
- Accelerator mode:
On views that could do with a boost, find and click the Caching option link in the Advanced section of the Views UI. It will reveal a new pseudo-caching option: None. Post-execution optimized by Views Accelerator. Select that. Revisit the page with the view(s) and compare performance stats to the screenshot you took earlier. Win? Then tell your boss or customer.
Evidence of performance gains
The map screenshot on this page was taken from a setup using IPGV&M in combination with Leaflet running over a view producing 1933 results.
Clustering occurred client-side (i.e. in the browser) via the Leaflet MarkerCluster module, contributing an additional 0.5 to 0.8 s (Chrome to Firefox) of client-side processing time, not incorporated in the figures below.
While the database query execution time was negligible, post execute and render times were considerable: over 10 seconds. After Views Accelerator was enabled this time was reduced to just under 4 sec, making for a more pleasant user experience.
You don't need IPGV&M to reap the benefits from Views Accelerator. For instance, you can use the Leaflet module by itself, without IPGV&M. However, you'll find that the map preparation time (the render component quoted in the Views Accelerator stats) of Leaflet is longer than IPGV&M's.
But it doesn't have to be maps. Views' tabular output can be accelerated in the same way. See the before and after screenshots below, where the same view as used for the map was rendered as one 1933 row table. Here too, we see more than double the speed in total server-side processing.
How it works
The time visitors spend waiting for Views to do its "thing" can be divided in four components:
- build the database query
- execute the database query
With the box Show performance statistics ticked, .../admin/structure/views/settings, Views produces performance stats for all but the third phase. Profiling has proven that this phase can take as long as the other three together!
Views Accelerator improves post-execution times by swapping out the
post_execute() function of views fields for a high-performant, low-rendering version.
In Views that cannot be cached (e.g. because they depend on an aspect of the visitor's profile, like their location) this can be highly effective on fields in your views that do not need to be rendered with their default markup, prefixes or suffixes.
Examples are fields used in Views-driven maps (Google, OpenLayers, Leaflet). Latitude and longitude fields are prime candidates, but also any fields used to populate the marker balloons that require little or no rendering like Address Fields or images.
Initial version sponsored by winemaps.com
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.
Q: What are the downsides to this module?
A: Performance acceleration established by this module comes from simplifying the post-execution and formatting/rendering of view fields. You may find that for some fields the simplification is taken a little too far. Entity Refs for instance, render as their target ids. We may be able to do something for other fields. Log an issue. If you have fields in your view that must be rendered in full, then you probably won't want to switch on the accelerator pseudo-cache for those views.
Q: What kind of views and fields can be accelerated?
A: Any View that contains Fields, as in fields from the Fields API, the ones you add to your user and content types via the "Manage Fields" tab. The module does not affect basic properties, like content title, content creation date -- those are already snappy.
Q: Does the Exclude from display box on a view field reduce time spent in the post-exec phase?
A: No. That box has no effect on post-exec times. Even on the render phase its effect is modest.
Q: When not using this module, but using a time-cache instead, the view would have a zero post-execute phase, right?
A: Not quite. When a view is cached, render and execute times certainly drop to near-zero. However the post-execute phase does not, as this is where loading of the cache takes place and this takes a little time. In the above example it is about 0.7 seconds.
Sites using Views Accelerator
Contact the maintainers to add your site here.
- Maintenance status: Actively maintained
- Development status: Under active development
- Module categories: Content Display, Performance and Scalability, Views
- Reported installs: 558 sites currently report using this module. View usage statistics.
- Downloads: 5,008
- Automated tests: Enabled
- Last modified: 4 December 2015
- This project is not covered by the security advisory policy.
Use at your own risk! It may have publicly disclosed vulnerabilities.