Troubleshooting › General Troubleshooting › Determining the Cause of a Problem

Determining the Cause of a Problem

1. Click the Operations page, select one or more components (the relative network, server, application) and click Links: Engineering to see your choices reflected on the Engineering page.
2. Click Components in the Show Me menu.
3. Begin your investigation with the Components report. This report is composed of various response time views stacked on top of each other to show how each contributes to the overall response time. The components in the Components report are:
   • Response Time Composition: Average
   • Server Response Time
   • Data Transfer Time
   • Retransmission Delay
   • Network Round Trip Time
   • Effective Network Round Trip Time

   Given a point in time on the view, the component color dominating the view indicates the component contributing the most delay to the overall application response time.

   Considered independently:

   • High values of Server Response Time indicate there could be issues with the server
   • High values of Data Transfer Time typically indicate that the application is the source of the problem
   • High values of NRTT or Retransmission Time typically indicate problems in the network
4. After you identify the component of response time that is contributing the most delay to the Component report, look at the individual view for that component by scrolling down the page of charts.
5. In the individual components view, notice how many observations were recorded when the issue occurred. The number of observations helps to identify the problem source: server, network, or application.

   The number of observations with respect to what is "normal" helps you to understand:

   • The significance of the event -- higher observation counts typically indicate a significant impact on the users of the application being analyzed, while lower values indicate the impact on end users was limited and/or not enough data points exist to analyze the issue.
   • The relevant contribution of the application of interest -- lower observation counts might indicate that the performance event was not caused by the application(s) being analyzed.
6. Follow the relevant process to confirm these results and to identify the source problem area as being the server, the network, or the application. In rare cases, a performance problem might have it source in more than one of the possible contributors, but that is unusual.

Consider these possibilities:

• Finding 1: A positive finding indicating that the problem source is the server, the network, or the application. For example, the data shows the server was the issue.
• Finding 2: A negative finding indicating that the problem source was not the network, server, or application. For example, the data clearly shows the network was not the issue.
• Finding 3: A negative finding indicating the problem source was not the final remaining network, server, or application. For example, the data further shows the application was not the issue.

The findings demonstrate that the server can be ruled in as the culprit while the network and application can be ruled out as not being culprits. With such a three-pronged finding, one might rest confident in identifying the root culprit and proceeding with remediation.

Note: Leave your mouse cursor at the point or interest in the Response Time Component view and use the down arrow keys to scroll down the page, bringing the lower views into view under the mouse cursor. As you move down the page with your arrow keys, the mouse pointer maintains its exact position on the screen, thus permitting you to easily align the given point on the Component view with the views that are lower on the page.