The RUM Transaction Details Page

You can zoom into transaction health of a particular page by clicking on the magnifying glass icon alongside its URL in the detailed diagnosis page. The RUM Transaction Details page will then appear. This page graphically represents the entire path of the page request / transaction, from the time the browser received the request to the time the server responded to it by serving the requested page. The time spent by the request at each step is also displayed in the graphic. A pie chart is also provided alongside that depicts what percentage of the page load time was spent at the browser, the network, downloading content, and the server. From the size of the slices in the pie, you can quickly and accurately determine where your request was delayed. If the pie chart reveals that Browser time is the reason for the poor responsiveness of a URL, then a quick look at the Browser Request and Browser Response break-up in the transaction flow chart will point you to why the request lost time on the browser - is it because the browser was slow in connecting to the server and processing the request? or is it because the browser was slow in fetching the resources from the server and rendering the requested page? If the issue was with the Browser Request, then the transaction flow chart also reveals why initial request processing by the browser was delayed - is it because the URL took too much time to follow redirection? or is it because the URL was waiting too long for a previous request to end? or is an AppCaching issue the reason?

If the transaction flow diagram reveals that a latent network is what is causing the transaction to slow down, then you can easily determine why the network is latent by moving your mouse pointer over Network Connection Time in the diagram. A break-up of the Network connection time will then pop up, indicating exactly when network connection was bottlenecked - is it when performing a domain lookup to access the web site/web application? is it when establishing a TCP connection with the server? or was there a delay in the SSL handshake?

If Browser Response is the bottleneck, then you click on the ‘magnifying glass’ icon under Browser Response in the page to know why. The Resource Details tab page will then open. To know more about this tab page, refer to The Resource Details Page section of this page.

The transaction flow diagram also provides you with useful information about the page being viewed such as the browser used to access the page, the page type, and redirection URL (if any). To view this information, click on the ‘down arrow’ icon you will find at the right, bottom corner of the Browser Request window.

You can also view user-related information in the transaction flow diagram. The geography to which the user who initiated the transaction belongs, client from which he/she is connecting, and the operating system of the client can be viewed by simply clicking the ‘down arrow’ icon adjacent to the user icon.

The Resource Details Page

If the RUM Transaction Details page reveals that the Browser Response is the bottleneck, then you can click on the ‘magnifying glass’ icon under Browser Response to know why. The Resource Details tab page will then open listing all the resources the browser was attempting to download from the server in response to the URL request, and the time taken to download each resource. This list enables administrators to pinpoint the precise resources that took an abnormally long time to be downloaded, thereby delaying page rendering. For instance, if resources such as CSS or JavaScripts are taking too long to load, they can be identified easily using the Resource Details page. This way, web masters can get insight into what resources to minify to get faster page load. Also, if there is a scenario where resources are being downloaded during each page load instead of being served from the browser cache, it can be found using this page.

To know where resource download was bottlenecked, click on the ‘magnifying glass’ icon alongside the problematic resource. A page showing resource fetch time break-up will then appear.

For a chosen resource, this page quickly reveals where resource download was delayed - on the browser? the network? or the server? If the delay was at the browser or the network, then the granular insights provided by this page will enable web masters to accurately identify the exact browser/network activity that caused resource loading slowness - redirection? AppCaching? browser wait? TCP connection? DNS lookup? or SSL handshake?

Similarly, if a delay in content downloading caused the transaction to slow down, then you can move your mouse pointer over Content Download Time in the flow diagram to determine where exactly content downloading was bottlenecked - during document downloading? or during document processing?

If a web page takes too long to download content, then users can quickly drill down from the detailed diagnostics of the content download time measure to view the load time of each resource in the Resource Details tab page. For this, click on the ‘magnifying glass’ icon alongside HTML Download/Processing Time (ms). This enables administrators to identify the exact resource in that page that is delaying the content download. You can even drill down from a particular resource in the Resource Details tab page to view where resource loading was bottlenecked.

Note:

eG Enterprise provides the resource-level visibility into page load time, by leveraging the Resource Timing API. The Resource Timing API enables retrieving and analyzing detailed network timing data regarding the loading of a web application's resource(s). A resource can be an XMLHttpRequest, image, script, etc. Now, if the users are accessing the monitored web page using the Internet Explorer (IE) browser, then sometimes, the load time of one/more resources may be displayed as -1 in the eG monitoring console. This is because, when monitoring page views from IE, the Resource Timing API reports ‘-1’ as the load time of certain resources. Also, some versions of Internet Explorer, do not support the Resource Timing API at all. When monitoring page views from such versions of IE, no resource metrics will be reported.

AJAX Requests in the RUM Transaction Details Page

AJAX requests are depicted differently in the RUM Transaction Details page. If a request makes an AJAX call to the server, then such a call will be tagged as an Ajax Call in the RUM Transaction Details page.

The Network connection time is included as part of Server time. This is why, in the RUM Transaction Details page for an AJAX request, by default, the Network connection time is not indicated. In the Detailed Diagnosis page also, the Network Connection Time column for an AJAX request will not display any value.

Typically, an AJAX function takes AJAX details as input along with a Callback reference. The Callback reference comes into play after the server processes the AJAX request. The Callback is generally used to communicate the result of the AJAX call to the caller, so that the caller can resume processing. For instance, say you have a function F1 which calls the AJAX function F2. F1 would like to know the result of the AJAX function F2 to proceed with its processing. For this, F1 will pass another function say C1 as an additional parameter to F2; C1 is the Callback reference. F2 will call C1 after it processes the AJAX request completely. C1 will communicate the result of F2 to the caller. The time taken by C1 - i.e., by the Callback function - for computing and sending the result to the caller is displayed in the RUM Transaction Details page as Ajax Callback Time.

Note:

• In the detailed diagnosis of an AJAX request, the Ajax Callback Time will be included in the Browser Render Time of that request.

• When reporting real-time metrics for an AJAX request, the Ajax Callback Time will be reported as Document Processing Time.

In summary, for AJAX requests, by default, the following metrics will only be displayed in the RUM Transaction Details page:

• Page Load Time

• Server Time

• Content Download Time

• Ajax Callback Time

In other words, the detailed break-up of response time, which is reported for other page types (eg., BasePage, iFrames), is not available by default for AJAX requests. This is because, the Enable AJAX Correlation parameter is set to No by default. You will find this parameter when you add a Real User Monitor component for monitoring using the eG admin interface.

To enable eG RUM to collect detailed response time metrics of AJAX requests, you first need to set the Enable AJAX Correlation flag to Yes. If this is done, then eG RUM will automatically correlate the default metrics it reports for AJAX requests with the insights that the ResourceTiming API offers for such requests. This auto-correlation enables eG RUM to provide the break-up of the response time of an AJAX request in the RUM Transaction Details page of that request.

A break-up of Browser Request time is now available for the AJAX request. The Ajax Callback Time is now been reported as the Browser Response time. Network Connection Time, which was earlier not reported for an AJAX request, is also now visible. To view the break-up of the Network Connection Time, you can even move your mouse pointer over the ‘magnifying glasss’ icon alongside that time value. The break-up will then appear.

If you want more granular load time metrics, you can switch to the Related Resource Details tab page, which appears next to the RUM Transaction Details tab page. For instance, let's say, the Browser Wait time (under Browser Request) is 2 milliseconds. Say, you want to know where or what the browser was waiting for. To determine this, click on the Related Resource Details tab page. The Related Resource Details tab page will then display the AJAX request being monitored. The AJAX request being monitored will be displayed under the RESOURCES column of the Related Resource Details tab page.

Click on the ‘magnifying glass’ icon alongside that request to zoom into it. This will display a complete break-up of load time of the AJAX request.

The Browser Wait time that you see in the RUM Transaction Details page is actually the sum of all the Block/Wait times displayed in the page that appeared. By comparing these Block/Wait times, you can accurately determine where the browser spent maximum time waiting. In the case of our example, this comparison reveals that the browser has spent maximum time waiting to send the request.

This way, every measure of time that you see either individually or collectively maps to a metric displayed in the RUM Transaction Details page. The mappings are detailed below:

With the help of these detailed metrics, you can quickly get to the root-cause of the poor responsiveness of your AJAX requests.

However, note that a few rules apply to the display of detailed load time metrics for AJAX requests. Even if the Enable AJAX Correlation flag is turned on, eG RUM will be able to report the detailed load time split-up of an AJAX request, only if:

• The URL of that AJAX request, as determined by eG RUM, exactly matches with the URL captured by the ResourceTiming API;

• The time of the AJAX request in eG RUM is at least close to the request time captured by the ResourceTiming API

• The AJAX request is well within the maximum number of resource requests a browser can handle

If even one of the aforesaid conditions is not fulfilled, then, though the Enable AJAX Correlation flag is set to Yes, the RUM Transaction Details page will report only four metrics, namely - Total page load time, Average server time, Average content download time, and Ajax callback time. The Related Resource Details page will also not provide any additional diagnostics.

Sometimes, more than one AJAX request processed at around the same time may have the same URL. At such times, eG RUM may find more than one match for an AJAX request's URL in the Resource Timing API. In this case again, even if the Enable AJAX Correlation flag is set to Yes, the RUM Transaction Details page will report only the four metrics mentioned above - i.e., Total page load time, Average server time, Average content download time, and Ajax callback time. However, the Related Resource Details page will display all the matching/related URLs. You can click on the ‘magnifying glass’ icon alongside a URL in the Related Resource Details page to view the detailed response time break-up for that URL.