Page tree

Skip to end of metadata
Go to start of metadata

With the evolution of Content Delivery Networks (CDN), web applications have evolved, and the browser retrieves content from a variety of servers.

A modern view of a web browsing experience

To calculate performance metrics, the system passively monitors your web traffic. However, if your web application uses a CDN, the system may need information from a browser to accurately calculate performance metrics.

BMC Real End User Experience Monitoring Software Edition enables you to set up monitoring for web applications with a CDN service.

A CDN is a large distributed system of servers deployed in multiple data centers in the Internet or on private networks. An origin server is where your web application content is stored, and it is monitored by BMC Real End User Experience Monitoring Software Edition.

Note

The first vendor providing cache servers for the web sites was Akamai, so for a long time the term Akamai was used to generalize all Content Delivery Networks (CDN). Now, there are many vendors on the market, so CDN became a more common term.

Because cached content does not always come from your origin server, deriving performance statistics for content served by an external provider might be challenging. By calculating statistics with special JavaScript code embedded in your web application pages, the system measures the page-render time when some of the content is cached or served by a CDN.

Example

Let's explore the loading of a page of a web application where some of the page components are served from a different web server than the container page.

Sample web page structure

Container

Assuming that the system is monitoring only www.acme.com and no other web server, it will treat Component 3 as the last component on the page, and will return an end-to-end time for the container, which is not the correct way of measuring. To deal with this deficiency, the system uses Edge instrumentation to provide a complete view of the page load. The only requirement is the system must see the container request.

The PRT is calculated by instrumenting the container page the end user views in the browser. The customer must insert a command to load a Javascript file at the beginning of the page (in the <head> section if possible). This Javascript file will start a timer and register a function with the page's OnLoad() event. When the browser has finished loading all components this event will occur and all functions attached to it will get executed. The Edge instrumentation function will stop the timer and generate a request to the origin web server (the same server that provided the container) for a Page Render Marker (also known as an User Defined Marker). The PRM request will carry URI Query parameters to calculate the PRT.

The advantage of having the PRT available for a container page is that it is a more accurate measurement of the page's loading time than end-to-end time when there are components loaded but not seen by EUEM. This PRT can be used in a Watchpoint, a report, a dashlet, a Page SLT, and available in the export APIs. The disadvantage of relying on PRT is that there is no breakdown into latency sub-components such as network time, host time, idle time, SSL time and redirect time.

Additional resource

Wikipedia contributors. Content delivery networks (From Wikipedia, the free encyclopedia)

Related topic

Setting up Akamai instrumentation to report page-render time