Site Building
Topic

Performance and Scalability for Drupal 8, 9, 10, and 11

When it comes to making your Drupal site faster there are two main areas of focus: performance and scalability.

Performance is how fast a single page can be served. This is affected by things like how long it takes your code to execute, the speed of the required database queries, settings in your web server, and other bottlenecks in the process of servicing a single request. Your best bet for improving this is ensuring proper configuration of modules. Then use a profiler to locate bottlenecks in your code. Either optimize them, cache the result to eliminate repeat processing, or both. Performance applies to the front-end of your site as well: the HTML, CSS and JavaScript impacts the performance of the user’s browser.

Scalability refers to how many concurrent pages your site can serve without adversely affecting performance. This is affected by limitations like how many requests the server can handle before it slows down, and considerations in Drupal’s code that allow for mitigating these limitations. It can be improved by making changes to your infrastructure that increase its ability to handle more requests quickly.

Example tasks

  • Configure Drupal core and contributed modules for optimal performance
  • Test a site’s performance and ability to handle multiple concurrent users
  • Make a Drupal site faster by using various caching systems like Varnish, Redis, and a CDN

Confidence

Our tutorials are up-to-date. There are other topics related to performance and scalability that we have not covered and are a work in progress. See the external resources for additional guidance on this subject.

Drupalize.Me resources

Categories
Drupal 8, 9, 10, and 11
More information

Drupal comes with all of its caching features enabled by default. This improves response time, but can be frustrating for themers as it makes it harder to preview the changes you make to template files.

In this tutorial we'll look at:

  • Why these features are enabled by default
  • How the theme layer leverages Drupal's caches
  • Why you should learn to disable them when doing development
Drupal 8, 9, 10, and 11
More information

Caching in Drupal is controlled by Drupal's Cache API which is used to store any type of data on a permanent or temporary basis. Some types of data tend to take a long time to compute, but utilizing the Cache API in your module can help your site load data more quickly.

Categories
Drupal 8, 9, 10, and 11
More information

The Render API is capable of detecting poorly-cacheable (highly dynamic) parts of a page and rendering them later using a process called auto-placeholdering. This works by using #lazy_builder callbacks to lazy load certain very dynamic subtrees of a render array. The place in the array where that very dynamic content would appear is first assigned a placeholder. At the very last moment it is replaced with the actual content.

This allows Drupal to do things like cache the overall page in the Dynamic Page Cache despite parts of the page being too dynamic to be worth caching. It also allows the Render API to assemble a page using cache fragments combined with non-cacheable elements.

In this tutorial we'll:

  • Discuss what lazy builders are and how they work in conjunction with placeholders to speed up the rendering pipeline
  • Cover some common gotchas for lazy builders
  • Look at some example code that implements a lazy builder callback

By the end of this tutorial, you should know how and when to use the #lazy_builder property of a render array and how Drupal uses placeholders to increase the cacheability of content and speed up the rendering process.

Categories
Drupal 8, 9, 10, and 11
More information

The individual items that make up the content of a page impact the cacheability of that page. In order for Drupal's cache and external caches to better understand how the content varies on a page, module developers use the #cache render element property. The #cache property defines cacheability metadata for individual elements in a render array.

Additionally, these Render API elements can become fairly complex. The calculation of what the final HTML output should look like often involves looking up content in the database, checking multiple conditions, maybe querying an external API, and various other tasks. This can cause turning a render array into HTML to become quite expensive. In order to speed up this process, the Render API will cache the generated HTML for each element and reuse it on future requests whenever possible -- but only if you tell it to do so.

In this tutorial, we'll look at:

  • How render caching impacts the performance of a page
  • Defining the cacheability of an item with cache tags, cache contexts, and cache max-age
  • Examples of using the #cache property in a render array

By the end of this tutorial you should know how, and when, to use the #cache property when defining render arrays.

Posted on Monday, October 17, 2016 - 02:07 by joe

I did some load testing to try and answer the question; How did moving our site from Linode to Pantheon affect the performance–measured in response time–of our site for both members and non-members?

Posted on Tuesday, July 21, 2015 - 08:01 by William Hetherington

Siege is a useful load testing tool to add to your performance testing tool kit. From the website: "Siege is an HTTP load testing and benchmarking utility. It was designed to let web developers measure their code under duress, to see how it will stand up to load on the internet. Siege supports basic authentication, cookies, HTTP, HTTPS and FTP protocols. It lets its user hit a server with a configurable number of simulated clients. Those clients place the server 'under siege.'"

Load testing is useful for testing the performance of your site, and the infrastructure that it runs on. There’s nothing worse than having one of your blog posts end up on Hacker News and then having your site crumble under the load. Siege can simulate activity on your site, and you can then use your site from your browser as you normally would, while your siege is running and really get a feel for how your site responds under load.

This blog post will cover installing Siege on OS X and Linux, and running a basic load test with Siege.

Guides

Not sure where to start? Our guides provide useful learning tracks for all skill levels.

Navigate guides

External resources