Leveraging New Relic or Blackfire for Performance Insightsfor Drupal 11 , 10 , 9 , and 8

Last updated :  

Devel and Webprofiler are excellent for debugging one request at a time, on a developer's own machine. They're the wrong tool for a different question entirely: "how is my production site actually performing, right now, across every real visitor, over the last week?" That's what dedicated APM (Application Performance Monitoring) tools like New Relic and Blackfire exist for — always-on, low-overhead monitoring of real traffic, not a debugging session you turn on and off.

What you'll learn in this lesson

  • Why production monitoring needs a fundamentally different tool than local debugging
  • What New Relic's APM agent actually measures continuously
  • How Blackfire's approach differs, and when to reach for it instead

Why Webprofiler doesn't scale to production

Webprofiler's own overhead (covered as a warning in earlier lessons) makes it unsuitable to leave running continuously on live traffic. It also only shows you one request at a time — useful for "why is this specific page slow," useless for "which of my 200 daily-active pages got slower after last week's deploy." Production monitoring needs to aggregate across thousands of real requests automatically.

New Relic: continuous, low-overhead APM

; A PHP extension, installed at the server level (not a Drupal module) —
; instrumentation happens transparently, no code changes required.
extension=newrelic.so
newrelic.appname = "My Drupal Site"
newrelic.license = "your-license-key"

New Relic instruments PHP execution at a low level via a server-installed extension, continuously sampling real production traffic with minimal per-request overhead — designed specifically to run always-on, unlike Webprofiler. It gives you dashboards showing response time trends over days or weeks, automatic slow-transaction detection, and error rate tracking, correlated against deploys if you wire up deploy markers.

Blackfire: deep, on-demand profiling

# Triggered on-demand against a specific request, not continuous —
# a deliberate profiling run, not passive always-on monitoring.
blackfire curl https://example.com/some-slow-page

Blackfire takes a different approach: instead of continuous low-overhead sampling, it produces a genuinely deep, function-call-level profile (a full call graph with per-function timing and memory) for one specific, deliberately-triggered request — closer in spirit to Webprofiler's depth, but built for a team workflow (shareable profile comparisons, CI integration to catch regressions before deploy) rather than one developer's local session.

These aren't competitors, they're complementary. A realistic production setup uses New Relic (or an equivalent like Datadog APM) for always-on trend monitoring and alerting, then reaches for Blackfire (or Webprofiler locally) for a deep, specific profile once New Relic's dashboards flag which page or transaction actually needs investigating. Neither replaces the other.

Quick check: your team wants to know immediately if a new deploy makes the site measurably slower on average, across all real traffic. Is Blackfire's on-demand profiling or New Relic's continuous monitoring the right tool for that specific question? If you said New Relic, you've correctly matched "continuous trend across all traffic" to the always-on tool, versus Blackfire's deliberate, one-request-at-a-time depth.

Key takeaways

  • Local debugging tools (Devel, Webprofiler) and production APM tools (New Relic, Blackfire) solve different problems — depth on one request versus trends across all traffic.
  • New Relic instruments continuously via a server-level PHP extension, designed for always-on production use with minimal overhead.
  • Blackfire produces a deep, on-demand function-call profile for one specific request, built for team workflows and CI regression detection.
  • Use continuous monitoring to know something got slower, and deep profiling to find out exactly why.

Coming up next

You've now got the complete performance-debugging toolkit, from local request inspection to production-grade monitoring. Next, we turn to a specific, extremely common real-world bottleneck: image handling — starting with building genuinely optimized image styles.