This article describes changes introduced in DC RUM 12.3 and DC RUM 12.4.5 and their possible impact on the values of operation time component metrics.

Idle time

What has changed

Starting from the 12.3 release, Operation time for analyzers supporting the Primary Reason for Slow Operations has a new time component, Idle time, previously available only in ADS.

Why we did it

In 12.2 and prior, operation time was calculated by summing all the individual hit times. We observed that if hits had significant gaps between them, they were either not included as a part of the operation time or attributed to network time. Starting with 12.3, this time is included in the Idle time component. Idle time is not a performance indicator - it is more of a context descriptor. It indicates that the client waited with sending subsequent page hit requests, but from the AMD point of view, it's difficult to determine what client was actually occupied with. It might have been the javascript processing in a browser, third-party content loaded by the client, or content from servers that are not within the scope of AMD monitoring.

Which metrics are affected

The Network time value might be lower, because the redesigned idle time refers to the fragments of operation that were previously attributed to network time.

Server time

What has changed

In releases 12.2 and earlier, server time was calculated only for the base hit. Now it is calculated for all hits in the operation. 

Why we did it

Calculating server time for all hits in the operation enables us to provide a more accurate and refined value.

Which metrics are affected

The Network time value might be lower, because the redesigned server time refers to the fragments of operation that were previously attributed to network time.

Other time

What has changed

Starting with 12.3, operation time for simultaneous TPC sessions has a new time component, Other time.

Operation time, depending on the type of communication, is calculated as follows:

For operations as a sequence of hits in the same TCP Session.

 Operation time = server time + network time + idle time

For operations as a collection of hits on simultaneous TCP sessions (hits overlapping)

 Operation time = server time + network time + idle time + other time

In the case of simultaneous TCP sessions with hit overlapping in place, the operation time components are calculated using the following criteria:

Server time - Part of operation time in which all the hits in simultaneous sessions were recognized as server time.

Network time - Part of operation time in which all the hits in simultaneous sessions were recognized as request time or response time.

Other time - Time that cannot be exclusively attributed to Server time, Network time, or Idle time as a result of hits overlapping. Note that the metric is not calculated  for simple operations completed in a single TCP session.

Idle time - Sum of client idle times between the hits.

Here is a simplified example of overlapping hits in an operation with simultaneous TCP session and how the operation time components are determined.

Why we did it

We decided to introduce the concept of Other time, because sometimes it is impossible to attribute the portion of time explicitly to a particular time component when hits in simultaneous TCP sessions overlap. This way, we are still able to provide the most accurate possible values of the operation time components under the circumstances of hit overlapping.

Which metrics are affected

Depending on your traffic profile, server time and network time may present lower values.

TCP and SSL handshake

What has changed

High Speed AMD, introduced as a part of the 12.4.5 release, does not include the time spent on TCP and SSL session establishment in the overall operation time. 

Why we did it

We observed that modern browsers pre-connect to the network automatically without any actions performed by the user. The browser simply starts the session when it is opened. If the user remains inactive for a longer period of time, taking into account the initial session establishment would artificially prolong the calculated operation time.

The CAS already provides the TCP SYN time metric that you can use to monitor the TCP handshake times.

Future DC RUM releases will also provide the SSL connection setup time metric.

Which metric are affected

Operation time, network time, and its component request time may present lower values.

Operation time - the complete picture

The bounce chart below gives a more detailed look into the calculation of operation time components. Note that the chart includes just the portion of the client-server communication significant to the context of this article.

  • No labels

5 Comments

  1. Would it be possible to have an example that shows information for DB as well? Would be very welcome

    1. Hi! Sure, it's a great idea. I'm adding this to the TechComm queue. We'll research this right away, but at this moment cannot promise any dates.

  2. Hi,

    I also have an interest in DB information. We saw the long idle time between application server and database server.

    Are there any idea about that?

  3. Where are the bounce diagrams in the 2017 doc?  I've searched multiple times, but only fine this one...

     

    -- Erik