Cloud Platform
Performance Pages & Drupal Improvements
When Drupal comes out of the box, it's configured for ease of development not performance. But making the application production-ready should indeed start with checking settings on the Performance page. The settings here let you control caching behavior and optimize bandwidth. If anything, it's a simple reminder to distinguish development settings from test and production settings to get the best results in each environment. This blog post, the last installment of a series that reviewed ways to improve Drupal website performance, offers some easy steps you can take to better your site.
An option on the Performance page turns on caching for anonymous users and for blocks. If block caching is turned on, even logged-in users will benefit. Unfortunately, this won't happen if content access modules limit users to specific content. If the application includes modules that implement node grants, the block caching feature will be disabled. It's also useful if you have content cached on a reverse proxy, like what is leveraged within Acquia Cloud. The "Expiration of Cached Content" setting tells the proxy how long to hold onto the page before requesting the latest version.
Don't forget the settings for individual modules. Depending on what you've loaded, you may have the ability to configure caching behavior in the admin user interface. Some modules have an admin interface that isn't needed in production, and you may be able to disable it to avoid the overhead.
Reducing the number of network requests and the size of files sent improves performance. Most Drupal sites have a few dozen CSS and JavaScript files. If these are compressed and sent in a single download, the number of requests needed and the size of the transmitted data are reduced.
You'd think a missing page would get a fast response, but by default, Drupal needs to perform a complete bootstrap to confirm the page doesn't exist. Fast 404 short-circuits this process and sends an error response immediately. Configure it by specifying the paths and file types that should send the error response.
The database is often the hardest place to optimize, but it's usually where the biggest bottlenecks occur. Eliminating unnecessary writes to the DB can lead to big gains in performance. By default, Drupal's Database module logs every event in the database. Instead, limit unnecessary log entries and use the Syslog module, which instead writes to the operating system's logs. Switching the logging destination is simple, doesn't really lose anything, and can significantly improve performance.
Performance tuning isn't a one-and-done process. As applications and users change over time, the performance they experience also changes. At Acquia, we use tools like Acquia Insight and New Relic to monitor sites and get suggestions for fixes. Acquia also has a Logstreaming tool that lets us see, live, what's going on with the site. Reacting to this information helps us understand how the site is working and recognize where additional changes are needed. I hope you enjoyed this series. If you have any questions or suggestions, please leave a comment below.
Cloud Platform