What does the Component Timings Area of a CEM Report show?

Products

• CA Application Performance Management Agent (APM / Wily / Introscope)
• INTROSCOPE

Issue/Introduction

Description:

This gives a high-level overview on the Component Timings Area of the Defect including sections and report function.

Solution:

The component timing table and graph can be found at the bottom of slow time defect detail. This feature has been available since CEM 4.5 and can be perplexing for many users.

Guidelines:

1. A good understanding of application components is invaluable in deciphering component timing performance.
   
   
2. After reviewing the defect component timings, it is helpful to see what is occurring at an incident level. This can be done by studying the transaction component pie chart on the Troubleshooting Tab.
   
   
3. Component timings can be added through reports by accessing the database table ts_tran_comp_details directly or through the export tool by specifying the optional -
   
   includecomptiminginfo parameter in the defects reports (Defects Data Commands 10-14,36-44)

Component Timing Overview

The following are the transaction steps that are involved with web servers and components:

1. The response is sent from the web server/load balancer to the web browser.
   
   
2. Part of the response is receiving the first component. It is loaded, parsed, and executed. Hereafter this will be called the web component lifecycle. This step also determines which additional components still need to be loaded. Then requests are made for these components (usually but not always in parallel).
   
   
3. Repeat the first two steps as many times as needed.

The APM component timing information consists of the following columns:

Name - the rows are the components associated with the transaction response. Typically the overall transaction component is first.

<Please see attached file for image>

Time to First Response (ms) - the time of the transaction from the request's last packet to the response's first packet. A time of 5000 ms (5 seconds) or larger is typically of concern and is indicative of server or network issues.

<Please see attached file for image>

Start Time - the time that the transaction is started to be received. The time is in the format YYYY-MM-DD hh:mm:ss.ms

<Please see attached file for image>

Transaction Time (ms) - the component's portion of the total transaction time from the start of the first request to the end of the last response. A time of 5000 ms (5 seconds) or larger is typically of concern and is indicative of web server issues.

<Please see attached file for image>

Size in KB - the observed size of the component that was loaded in the web browser

<Please see attached file for image>

Time Line (ms)- the barchart shows the entire lifecycle for one component. The barchart is separated into two parts - the time to first response and the response transfer time. A color key is shown below:

<Please see attached file for image>

Other information

The bottom left hand corner of the chart lists the number of items found and links to other pages if there are many components.

<Please see attached file for image>

Interpreting the Chart

Much interpretation of the chart is straight forward - it is easy to see which component is the slowest and the fastest. But interpreting other issues may not be as clear.

Here are three special cases:

Case 1: Time to First Response is almost as long as the Transaction Time

The first case is usually an indication that the application server or network is experiencing slowness. The defect detail information alone is not enough to determine the root cause of the slowness..

Case 2: Transaction Time is longer than the Time to First Response

The second case is an indication that the network or remote client is experiencing slowness. The defect detail information alone is not enough to determine the root cause of the slowness.

<Please see attached file for image>

Case 3 Gaps between components

One popular question is why are there gaps between the component bar graphs such as shown below.

<Please see attached file for image>

The gap is due to the operation of the HTTP protocol and HTML layout operations.

For example, if there are dynamic components that load after the prior components and then refer to additional components, a gap will exist. Other factors include:

1. The type of browser (which impacts layout speed, web standards supported, javascript engine, etc.)
   
   
2. Computer Speed. Certain computers will do everything within a paging file.
   
   
3. The speed of the web server response. (It may be impacted by proxy servers, load balancers, etc.)

Here is the above example annotated:

<Please see attached file for image>

In the above graph, the following sequence is happening:

1. The active content PHP page is loaded first (0014 Faq View)
   
   
2. The seven other static components are loaded. This is usually in the same order as the page parsing identified by the browser.
   
   
3. The last static component is loaded by the browser.
   
   
4. Finally, the web page is correctly displayed after all components are loaded.

Here, you can see gaps between the active content, the seven static components and the last component. This is due to the time it takes to load, parse, and execute these components. This total amount of time for all components contributes to the transaction response time.

Note that the start times also indicate that some types of components are being loaded in parallel rather than sequentially.

Limitations

1. The number of components that can be displayed and the sort order (affecting appearance of components) is not configurable at this time.

Environment

Release:
Component: APMCEM