New Relic & Drupal: Find Your Site's Slow Spots

Drupal sites running on Pantheon just received a boost with the addition of New Relic APM Pro. Application Performance Monitoring gives you deep insight to the behavior of your site. For a great overview of the partnership, please watch our New Relic APM Pro webinar. In this video, Pantheon co-founder Josh Koenig reviews the data on a copy of pantheon.io:

Add New Relic to Your Drupal Site

Setting up New Relic is easy. Turn it on with one click from the Pantheon dashboard and traffic in all environments will be recorded. Our New Relic docs show more details and additional options.

Drupal-Specific Integrations

One of the main benefits of New Relic is that it can give you data at different levels of granularity. You can zoom in from high-level average page load times all the way down to the number of milliseconds spent in each function call on a slow page. The Drupal-specific data offered by New Relic is a good middle ground starting point. It allows you to view performance from some of Drupal’s fundamental building blocks:

• Modules

• Hooks

• Views

For each of those levels you can see rankings by:

• Most time consuming

• Slowest average call time

• Function call count

Any combination of those metrics might reveal helpful insights. Let’s look at three possible combinations.

Slowest Average Call Time and Views

Here we are seeing real data from pantheon.io, the very site you are reading. The slowest View by average call time is our staff listing. This is likely a great example of the need to track performance changes over time. That View would not have been at the top of the list when Pantheon was a smaller company. With each employee we add, that View will get a little slower. This data can inform decisions about further optimizations. First we might look for ways to make the View render faster; directly bringing down this metric. Next it may be worth talking to stakeholders about the number of employees at which we would revisit the design of our team page. We could also raise the cache lifetime of this View so that it is built less frequently.

Function Call Count and Hooks

Looking again at Live data from pantheon.io, I see that hook_tokens() is called most often.

This chart reminds me of a performance problem I found the first time I used New Relic. My former co-worker Larry Garfield wrote an in-depth analysis on the Palantir.net blog of how we handled a situation where token-related hooks were at the top of the list by orders of magnitude. In that case, Larry found places to patch a contrib module. Here, where hook_tokens() exceeds hook_init() by roughly five-to-one, the ratio is not as extreme. If our team determined that we needed to bring this number down, we could investigate whether a specific configured usage of Token module accounted for most of these calls.

For most teams, I would recommend relying on Pantheon’s different environments to look for differences in New Relic data while developing a site. A team member might be developing a 3rd-party integration that relies on Token module in a Pantheon Multidev environment. If the New Relic stats in that environment show a huge jump in Token calls, it might be wise to double check the configuration before merging.

Most Time-Consuming Modules

The “most time-consuming” stat is a function of the previous two. These numbers will rise as something is called more often and with the time spent in each call.

These stats are from missionbicycle.com. Here, I want to warn against chasing every high number. In this chart, Rules module is at the top of the list of most time consuming modules. Someone could see this chart and think “See! Rules module is slow and should be removed.” In many cases, modules will show up near the top of these lists for good reasons. As a site using Commerce suite, Rules is responsible for much of the ecommerce business logic. Removing it would require completely rearchitecting the site. New Relic data is most helpful when paired with an understanding of how the site was constructed.

Leveraging Quicksilver Platform Hooks

When making performance optimizations you want to see a clear drop in response times after deploying your changes. Here’s an example of response times as a script executes common administrative tasks on a plain Drupal 8 site. There’s a sharp drop as the site changes from PHP 5.6 to PHP 7.

As we know, PHP 7 makes sites a lot faster and it is easy to spot where the change happened in this case. Additionally we have a New Relic deploy marker (one of the vertical lines) signaling when the change to PHP 7 occurred. Adding this deploy marker automatically with each code change is easy with Pantheon Platform Hooks. Just modify your pantheon.yml file and add the Quicksilver script to your site as shown in our repository of example integrations.

Putting it all together

In addition to marking your deployments with the above example, our Platform Hooks also can help ensure your deployments change Drupal in the ways you expect. You can trigger a revert of Features in Drupal 7 or an import of configuration in Drupal 8. When procedures like these are scripted, you can be more confident in the changes you see following a deployment marker.