High Performance Drupal

Chapter 5. Drupal Coding for Abysmal Performance

Having looked at some Drupal best practices for performance, we’ll now take a look at some worst practices and antipatterns. No one intentionally writes abysmally performing code, but as with any system, misuse of Drupal APIs can lead to unexpected and hard-to-predict performance issues that are often hidden in the implementation details of a specific API.

It’s not possible to provide an exhaustive list of antipatterns in Drupal that are bad for performance, but one API in particular gets abused very frequently and can cause quite serious and hard-to-track-down performance issues on high-traffic sites with particular configurations.

variable_set() Abuse

The variables system prior to Drupal 8 is one of the simplest, most central, and most commonly used APIs, to the point where it’s very rare to find a module that doesn’t use it. It’s also one of the most frequently abused APIs, including in Drupal core, so it provides a good example of how a simple API can come to be misused over time as use cases change. As you’ll see, this API no longer exists in Drupal 8.

We’ll start with a brief explanation of the API and its implementation in Drupal core.

Variables are stored in a single table with a name and a serialized value. Early in each page request, every variable is loaded into the $conf global from the cache (or the cache item is rebuilt if it’s missing). Individual variables are accessed, set, or deleted via the variable_get(), variable_set() ...