Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Using New Relic APM to Troubleshoot Performance Problems

DZone's Guide to

Using New Relic APM to Troubleshoot Performance Problems

· Performance Zone
Free Resource

[This article was written by Phil Weber]

One of the most common questions we hear from customers is, “My application is running slowly; how do I use New Relic to pinpoint the cause?”

To use New Relic to troubleshoot a performance problem, follow these steps:

  1. Starting with an overview graph, such as Browser Page Load or Transaction Response Time, determine which element is taking the most time;
  2. Select the corresponding link or menu item to see more detail;
  3. Repeat as desired to drill down.

Let’s look at an example.

Step 1: Starting with an overview graph, determine which element is taking the most time

Imagine that one of your customers reports that your site is running slowly. You bring up the application’s dashboard in New Relic Browser.

Browser screenshot

Which element on the Browser Page Load Time graph is taking the most time? [click to enlarge]

According to the legend, the Browser Page Load Time graph displays times for Request queuing, Web application, Network, DOM processing, and Page rendering. Which of these elements is taking the most time (which item is largest on the graph)?
Browser screenshot

[click to enlarge]

Step 2: Select the corresponding link or menu item to see more detail

To see more information about the Web application’s response time, click the App Server link above the Browser Response Time graph.

Browser link to app server

Step 3: Repeat as desired

On the application overview page, we see another graph, which brings us back to Step 1: Which element on this graph is taking the most time?

Transactions 1

[click to enlarge]

Transactions 2

Select the Transactions menu to see where your code is spending its time. [click to enlarge]

It’s pretty clear that in this example, the home method of the PagesController is the most time-consuming. From here, you can look at a transaction trace or use New Relic’s thread profiler to drill down further and see what’s taking so long (Step 3).

A JDBC and Postgres example

What if a different element of the Transaction Response Time graph had been the largest?

Databases 1

[click to enlarge]

In this example, JDBC and Postgres are the largest elements, indicating that most of the time is being spent in the data access layer. Select the Databases menu to see more detail.
Databases 2

Select the Databases menu to see which queries are the most time-consuming. [click to enlarge]

The Databases dashboard shows that JDBC condition_alertables select is consuming the most time. From here, you can select individual queries to see where they’re being called, and the SQL code of the slowest queries.

A Web External example

One more example:

Externals 1

[click to enlarge]

This time, Web External is the largest element, indicating that calls to out-of-process services are the culprit. Select the External Services menu to see more detail:
Externals 2

The External Services dashboard shows which services are consuming the most time, and where they’re being called in your application. [click to enlarge]

New Relic is designed to help make troubleshooting easier and to point you in the right direction with minimal effort. Just remember the three steps:
  1. Starting with an overview graph, such as Browser Page Load or Transaction Response Time, determine which element is taking the most time;
  2. Select the corresponding link or menu item to see more detail;
  3. Repeat as desired to drill down.

Consult these resources for more information:

Topics:

Published at DZone with permission of Fredric Paul, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}