Skip to main content

Monitor and Improve Site Performance

Learn how to use New Relic to monitor and improve site performance.


This section provides information on how to monitor and improve site performance with New Relic®.

Info:
Note

Please contact support if you encounter a permissions warning in New Relic while following the steps below, or if you can't access these features.

Monitor and Improve Performance

New Relic®'s Dashboard opens with a high-level breakdown of application performance by dividing response time into three segments in its main graph:

  1. PHP Execution

  2. Database Queries (MySQL or Redis)

  3. External Requests (calls to third-party APIs)

Depending on which area you need to optimize, you will explore different areas of data. For instance, a lot of time spent in the database could be the result of slow queries, or an elevated volume of queries overall.

For more information on using New Relic®'s features, we encourage you to review the New Relic® APM docs, especially the pages on transactions and slow query details. You can find more information on using New Relic® to investigate specific areas of performance below:

Configure Ping Monitors (Synthetics) for Availability

New Relic provides an availability monitoring service within their Synthetics tool suite which can be enabled by contacting support. This basic monitoring feature sends a request to designated URLs from configured locations. Requests are sent at configured intervals and alerts are sent via email when a response fails.

Pantheon provides unlimited New Relic Synthetics ping monitoring as part of the service. Still, there's a quota for all other monitor types (simple browser, scripted browser, and scripted API monitors). This quota is set at 10K Synthetics monthly checks for each Pantheon account, so it's crucial to manage it effectively.

Info:
Note

When a Pantheon workspace has more than 10K Synthetics checks are running monthly Pantheon will adjust the frequency or number of locations a Synthetics check originates from the reduce the number of checks. This is required to allow Synthetic to continue to operate correctly under the overall New Relic quota for Pantheon.

More advanced monitoring, including full browser testing and scripted interactions, is only available to customers on an annual contract and requires an additional cost. Contact our sales team or your dedicated account manager for more information.

Follow the steps below to configure the monitor service.

  1. Click New Relic, then go to New Relic from the target environment within the Site Dashboard on Pantheon.

  2. Select Synthetic Monitoring from the main menu.

  3. Click Create Monitor in the Monitors tab (default) and enter the details for the URL you want to monitor.

  4. Select the locations you want to check the site from. We recommend picking locations that correspond to your site's visitors to reduce the risk of false-positives due to long-distance network mixups.

  5. Set the frequency for checks. We suggest five minutes.

  6. Provide an email address for notifications.

  7. Click Save monitor.

Enable Drupal Hooks & Modules Metrics

As of April 23, 2024, Drupal hooks & modules metrics are not reported by default. To enable this reporting, add the following to your site or upstream pantheon.yml file:

pantheon.yml
new_relic:
  drupal_hooks: true

Focus on Authenticated Users Only

It can be useful to exclude anonymous users who are using your site's page cache if your site consists of mostly authenticated traffic. This technique will still capture form submissions, including logins and contact pages. Similar logic can be used to disable New Relic® on certain paths, such as /admin in Drupal or /wp-admin in WordPress.

Drupal

To disable New Relic® for anonymous traffic on Drupal-based sites, add the following code to your sites/default/settings.php:

settings.php
// Disable New Relic for anonymous users.
if (function_exists('newrelic_ignore_transaction')) {
  $skip_new_relic = TRUE;
  // Capture all transactions for users with a PHP session.
  // (SSESS is the session cookie prefix when PHP session.cookie_secure is on.)
  foreach (array_keys($_COOKIE) as $cookie) {
    if (substr($cookie, 0, 4) == 'SESS' || substr($cookie, 0, 5) == 'SSESS') {
      $skip_new_relic = FALSE;
    }
  }
  // Capture all POST requests so we include anonymous form submissions.
  if (isset($_SERVER['REQUEST_METHOD']) && $_SERVER['REQUEST_METHOD'] == 'POST') {
    $skip_new_relic = FALSE;
  }
  if ($skip_new_relic) {
    newrelic_ignore_transaction();
  }
}

WordPress

To disable New Relic® for anonymous traffic on WordPress sites, add the following code to your templates/<your_template>/functions.php:

functions.php
// Disable New Relic for anonymous users.
if (function_exists('newrelic_ignore_transaction')) {
    $skip_new_relic = !is_user_logged_in();

    // Capture all POST requests so we include anonymous form submissions.
    if (isset($_SERVER['REQUEST_METHOD']) &&
        $_SERVER['REQUEST_METHOD'] == 'POST') {
        $skip_new_relic = FALSE;
    }

    if ($skip_new_relic) {
        newrelic_ignore_transaction();
    }
}

False Alarms

Availability monitoring services (for example, Pingdom and New Relic® Synthetics) function by periodically reaching out to sites to gauge availability. Some failures in availability do not require action and can be considered false alarms, such as failures due to internet routing or idle containers.

Internet Routing

A temporary routing issue between a particular monitoring service endpoint and one of our CDN CHI metro Points of Presence (POPs) can result in an alert. The internet is a big place, and there's a lot of potential for intermittent packet loss between any two points, depending on the route taken. A single loss of access from one point to another does not always correlate to an issue with the site itself.

Tools like MTR can help to diagnose a routing issue.

Idle Containers

Containers on Pantheon are automatically spun down following a period of inactivity, then spun back up once a web request is made. Monitoring pings sent between the initial request and the completed spin-up may fail, but do not necessarily indicate an issue. For details, review All About Application Containers.

Support for Handling Alerts

Before opening a support ticket based on an alert, take the following actions:

  1. Refer to the alert message to confirm the event reported (what monitor it came from, what triggered it, etc.).

  2. Determine whether the event was a false alarm.

  3. Contact support after you have verified an outstanding alert and provide the following information:

    • Steps to reproduce the issue (including URLs or paths to files)

    • Environments affected (Multidev/Dev/Test/Live), if applicable

    • When the issue began

    • Error messages received

    • Links to screenshots or screencasts of the behavior, if necessary

    If the issue creating the alert stems from the Pantheon Platform, we will investigate and resolve it. Alerts triggered by the site's code are not within Pantheon's scope of support. For details, refer to Getting Support.

More Resources