At Creode, we frequently take on a number of clients with existing Drupal websites. Whilst the reasons for moving the management of their sites are varied, one common complaint is the speed of the existing site.
In order to improve Drupal performance issues, we provide our clients with a report of their existing site including a performance audit and methods for tuning Drupal to improve speed. Below is a list of the most frequent causes of poor performance that we see:
1. Large Views Queries
In older versions of Drupal/Views, the addition of multiple fields, sorts, joins and groupings could cause very large queries, with multiple tables being joined together. On smaller hosting platforms this can result in database bottlenecks.
2. Large Views results
With the addition of Entities in Drupal 7, Views moved into using Entity Load to bring back views results data. Whilst this reduced the number of table joins in the main views query, it increased the usage of the entity_load function. If you are pulling back a large dataset of entities on a single page (such as plotting results on a map), consider the fact that views will be performing a full Entity Load on each.
3. Slow queries
Often the result of custom modules, it is important to identify the slowest queries on poor performing pages and benchmark them. Are all the queries written as efficiently as possible? Benchmarking should be done with a large dataset, as even a poorly written query will perform ok on small datasets.
4. Number of queries per page load
Due to the procedural codebase behind Drupal 7 and older, a lot of queries are loaded on each page in comparison to platforms built using Object Oriented Programming. The more queries a page runs, the more times the database or cache is hit. This may impact the load on the database and server, causing potential bottlenecks in load time.
As a rough rule of thumb we would become concerned should a page show a query count of more than 500 on a single page load (although we have seen instances of over 10,000 previously).
The cause of this is often an overuse of modules, or poorly written custom modules making excessive database queries within code loops.
5. Number of files loaded per page load
Much like the above point, due to the Drupal architecture, every page load will call a significant number of files to render the page. A high number of files would put excessive strain on the processor, RAM and Hard Drive.
We would anticipate a figure of under 400 files to be loaded on key pages of a mid-weight Drupal site, so figures over this could impact performance.
The cause of this issue is normally due to an excessive use of Drupal Modules, or a high number of theme/template files (where possible theme functions should be chosen over template files for performance).
6. Number of Modules
The beauty of Drupal, is the vast amount of modules out there performing any number of different tasks, and adding a great level of functionality to a site. Unfortunately, every module installed on a site will have a performance impact, as some of the files within the module will be processed on every page load even if the core functionality is not used.
Not only does this apply to enabled modules, but also to disabled modules, so if a module is not being used, uninstall it and delete it from the system.
7. Bad modules
Some modules are simply bad for performance, and unless really necessary, we believe they should not be used, so let’s all disable:
- Administration Menu (not to be confused with Toolbar)
- Database Logging
8. Lack of Caching
Caching in Drupal improves performance significantly. Whilst the above issues should be addressed first, adding caching to a well performing site will make it blisteringly fast. Views Caching, Block Caching, Page Caching, Panels Caching etc should all be considered depending on site requirements. Add further server caching on top of this such as APC, Memcache, Varnish etc to give brilliant results. Setting the appropriate cache limits for each of these is as vital as adding the functionality itself, so be rigourous.
9. Aggregate JS/CSS, compress files
We commonly see sites with aggregation turned off resulting in a large number of JS/CSS files from different modules being loaded via the site Head, and with compression needlessly disabled. correcting these is a quick win.
10. Custom Modules
There is a huge difference in skills from one Drupal developer to the next, and no doubt your site will have had some form of custom modules added to it if a developer has been involved in the project.
Ensure any custom code is written efficiently, using the correct Drupal standards, and caching implemented into the code will ensure these modules don’t become bottlenecks. If the modules have install files adding tables to the database, also ensure these have indexes applied to prevent slow query issues.
Drupal uses a large amount of memory, regardless of if the above has been carried out. As such, a decent server platform with enough available resource for both your site and the traffic expected is required. Putting a Drupal site onto a cheap, shared hosting package does not end well.
We would love to hear the most common performance issues others have come across on Drupal sites.