Cloud Platform
Using New Relic to troubleshoot site issues
Website slowness is one of the most common issues web developers have to troubleshoot. It can also be one of the most difficult issues to identify. Network speeds, hardware sizing, website traffic levels, code quality, and configuration are just a few of the factors that can contribute to a website s speed or slowness.
To improve our customers ability to diagnose and resolve website performance issues, Acquia has partnered with New Relic, an Application Performance Monitoring (APM) solution. New Relic allows customers to analyze their website performance over time, and zoom in on specific time periods to see what may be contributing to the website's slow page load times. For more information about using New Relic with your Acquia subscription, see About New Relic.
Follow the instructions on Configuring performance monitoring tools to setup New Relic with Acquia Cloud.
Once your application receives sufficient traffic, you will begin seeing data appear in the graphs on New Relic's website.
To get started using New Relic's interface, see The New Relic User Interface.
New Relic's dashboard provides an abundance of data, but not all of it may be relevant to your troubleshooting needs. When Acquia's Global Support Team uses New Relic to diagnose issues, its primary focus is on the Web transactions graph. This graph allows you to see the amount of time, on average, pages are taking to load, and it divides that time into four components: PHP, Database, Memcache, and Web External.
In total, a healthy response time is usually around 1000 milliseconds (ms) or less during periods of normal traffic. A response time of well under 1000ms is generally considered to be fast, whereas a slow response time is 1250ms or more.
For more information about New Relic's user interface and dashboard, see the articles Understanding the UI and Using the Dashboard.
By clicking on either the left menu in New Relic or on the main graph, you can learn more about each layer of the webpage request process.
The Transactions webpage lists the slowest requests detected during a specified time period. Acquia Support generally recommends filtering the results by Slowest Average Response Time, as this will give you a more general overview. Keep in mind that the slowness associated with a specific request on your website can be caused by the code, database, Memcached, or external processes associated with that webpage, so additional investigation is usually required before you can identify what, specifically, is slowing down the website.
The webpages titled Modules, Hooks and Views deal specifically with Drupal code. You will only see these options in your menu if New Relic was installed with the Drupal Monitoring option enabled. This is now the default configuration on Acquia Cloud; however, customers with older New Relic subscriptions may not have this feature enabled. If this is the case for you, please contact Acquia Support for assistance.
The Modules webpage lists the most common sources of slowness on your website, organized by Drupal module. Again, you will want to filter the list based on Slowest average call time, although the graph at right will still show the slowest overall modules. Both perspectives can be useful in identifying modules slowing down your website.
Note: The module code or configuration itself may not be the cause of a website's slowness; this module may instead be making slow calls to the database or external services.
The Hooks webpage lists specific Drupal hooks associated with slowness. On most Drupal websites, init will be the slowest hook, since it does the most overall work. Other potentially slow hooks are node_view and block_view, indicating that a website is being slowed down by those specific components of a page request.
The Views webpage lists the slowest views created by the Views module. Views are a common source of website slowness, especially if they are not properly cached. Adding caching to your blocks, views, and pages will help speed up your website.
The Database webpage is often one of the most telling sources of website slowness, since it can cause spikes in the webpages mentioned above. The information on this page informs you if there is a problem with the volume or complexity of requests to the website. Even fast requests to your database can slow down your website if a lot of these requests come simultaneously. If a few slower database queries come along with faster ones, they can temporarily lock up tables or back up subsequent requests, forcing them to remain queued before MySQL processes them.
You can improve your website's speed by reducing the complexity of queries to the database.
The External Services webpage lists the slowest calls to remote websites by your application during the web request process. It does not list slow calls made when the browser is attempting to render your website; instead, it lists the calls made when attempting to pull data and process logic before sending information back to the browser to be rendered.
Most often, calls to remote APIs and databases will appear on this page. In instances where those services are slow or experiencing downtime, your servers will not be able to acquire the data they need to respond. You will usually see a white screen on your website, a Temporarily Unavailable error, or a hanging page request.
By contrast, if your website is configured to contact a remote service during the page rendering process, then your web servers are able to provide users with all of the data they need to start rendering the website. However, the webpage will load slowly because they cannot connect to the remote service themselves. This type of behavior will appear on New Relic's Browser monitoring section, not the Application monitoring section detailed in this article. For more information about the Browser monitoring section, see Browser settings: UI options for browser monitoring on newrelic.com.
If your own website's own domain(s) appear in the External Services list, this usually means that your website is making a page or API request to itself in order to respond to a previous page request. During periods of high traffic, these self-referential calls can begin to back up on each other, since a slow page request on your website spawns a second request to the same website (or a related one) which, itself, is slowed by the pending response to the first request. This can be problematic for websites which call themselves, websites which call other websites in a multisite setup, or websites which call other websites on the same hardware. For more information about how to set up New Relic for a multisite configuration, see Using New Relic monitoring in a multisite environment.
From New Relic documentation:
In Drupal 7.15, Compress cached pages is turned on by default. If you also select Cache pages for anonymous users, the JavaScript (newrelic.js) is not inserted into the served pages for anonymous users. This is because Drupal's pages are compressed directly from the database before they are stored in the cache (with gzip), so New Relic's PHP agent does not have a chance to parse any HTML. In this situation, manual instrumentation provides a better opportunity to capture data for anonymous users.
To correct this, you can use this drush command from the command line, inside the docroot of the website:
drush --uri="www.example.com" vset page_compression 0
Cloud Platform