End User Experience Monitoring (EUM)/User Experience Monitoring (UEM) Analyzer

End User Experience Analyzer provides detailed performance of web applications as experienced by actual end users. Applicare agent automatically injects Java script code to JSP pages and that reports back the total time it took to load the page from the time a user clicked the link, network time, server processing and browser rendering times, browser type and user location.

Configuration

Applicare scripts for gathering EUM data are by default served by Applicare Controller but can be served by any Applicare Collector instance. Following JVM arguments need to be set in case a collector is serving these scripts and persisting returned data

Example URLs below assumes that 192.168.1.10 is the IP address of the Applicare Collector and 8080 is the port it is listening on. DO CHANGE that IP and Port when copying these arguments and adding them to agent start.

Most important step is to make sure that these scrpts and beacon URLs are accessible to the web page end users. You may have to configure firewall rules to allow external access to these URLs.

If you specify the above parameters then Applicare will insert java-script similar to following when the end user accesses any page generated by a jsp/servlet of your application.

<script src="https://192.168.1.10:8080/applicare_agent/eum/arc-eum.js" type="text/javascript"></script>

<script type="text/javascript">

BOOMR.addVar({ "server": "AdminServer","t_backend": "4","b_name": BrowserDetect.browser,"b_ver": BrowserDetect.version,"b_os": BrowserDetect.OS });

BOOMR.init({user_ip: "192.168.1.16",beacon_url: "https://192.168.1.10:8080/applicare_agent/eum/beacon"});

</script>

Next you need to enable End User Experience Profiling aspect on your servers to automatically inject Java script code to JSP pages. This can be done by.

• Navigate to Configuration > Configure Dynamic Instrumentation page in Applicare console.
• On IntelliTrace Deployment tab, select Advanced Mode and click Configure button next to it.
• Move End User Experience Profiling aspect from left side list to Deployed Aspect list by selecting the aspect and clicking Add button.
• Click Apply button and make sure Agent is enabled for servers in IntelliTrace deployment tab.    

Programmatic javascript Injection

If for some reason auto-instrumentation does not work or you can not use auto-instrumentation, end user monitoring can still be used by programmatically injecting appropriate scripts in your pages.

Applicare includes an API to which you can add to your page just before end "</body>" and it will inject the required javascript in the page.

For example, you could modify your application's template for manual javascript inject as follows:

... existing template code ...
<%= com.arcturus.aop.shared.RUMManager.injectJS() %>
</body>

Additionally, you will need to add "<Applicare Installation Dir>/applicare-aspects.jar" to your classpath during the development process.

Manual javascript Injection for static pages

For end user experience monitoring of static pages Applicare EUM scripts can be manually injected.

URL Exclusion & Inclusion

You can select a URL from HTTP Analyzer and add it to UEMURLExclusions.txt to exclude it from UEM.
Similarly, you can select a URL from HTTP Analyzer and add it to UEMURLInclusions.txt file to include it in UEM.

Analyzer

End User Experience Analyzer displays historical data related to end user performance broken down by different aspects in separate tabs. Data will be dispalyed on the Realtime Transactions tab as soon as users start accessing your application. It may take a few minutes for data on other tabs to show up.

Overview

The world map on the dashboard shows the performance breakdown for each country. Mouse over a country to see performance summary data for the country. On the right you can view top transactions by different criteria such as page count, average page load time etc... The chart below shows the performance data over the selected time period and if you click on a country in the map, the chart will display the performance data for the country as shown in the image below.

Transaction Summary

Transaction summary view displays performance statistics of transactions for the selected time period along with the time line chart at the bottom. Clicking on a transaction will update the timeline chart to display performance data for the selected transaction.

Realtime Transactions

Realtime view displays the last n number of individual transactions recorded. Along with performance stats you can view location and browser information of users accessing your application. This view doesn't show any transactions older than a day.

In case the Applicare Controller/Collector collecting EUM data is behind a proxy, firewall or load balancer, make sure that the proxy, firewall or load balancing server forwards the client requests with "X-Forwarded-For" header parameter. If this parameter is not included in the HTTP request then Applicare may show the IP address of proxy, firewall or load balancing server in End User Experience Analyzer.

Below are the details on monitored data shown for each transaction

• Resource Fetch Time: The time it takes for a web browser to fetch a resource, such as an image, CSS file, or JavaScript file. This includes the time it takes to:
  • DNS lookup: The time it takes to resolve the domain name of the resource.
  • TCP connection establishment: The time it takes to establish a connection to the server that hosts the resource.
  • TLS handshake: The time it takes to establish a secure connection to the server, if the resource is hosted over HTTPS.
  • Request: The time it takes to send the request for the resource to the server.
  • Response: The time it takes to receive the response from the server, including the time it takes to download the resource.

    Resource Fetch Time is an important metric for measuring the performance of a web page. A short Resource Fetch Time means that the page will load more quickly, which can improve the user experience.

    There are a number of factors that can affect Resource Fetch Time, including:

    • The size of the resource: Larger resources will take longer to fetch.
    • The speed of the user's internet connection: A slower internet connection will result in a longer Resource Fetch Time.
    • The performance of the browser: A faster browser will be able to fetch resources more quickly.
    • The location of the server: The closer the server is to the user, the shorter the Resource Fetch Time will be.

    Here are some tips for improving Resource Fetch Time:

    • Use minified and compressed resources: Minified and compressed resources are smaller, which means they will take less time to fetch.
    • Use a CDN: A CDN (Content Delivery Network) can deliver resources from servers that are closer to the user, which can improve Resource Fetch Time.
    • Use a caching mechanism: A caching mechanism can store resources that have already been fetched, which can reduce the need to fetch them again.

• Document Download Time: The time it takes to download a document from a web server to a user's device. This includes the time it takes to:
  • DNS lookup: The time it takes to resolve the domain name of the web server.
  • TCP connection establishment: The time it takes to establish a connection to the web server.
  • TLS handshake: The time it takes to establish a secure connection to the web server, if the request is made over HTTPS.
  • Request: The time it takes to send the request for the document to the web server.
  • Response: The time it takes to receive the response from the web server, including the time it takes to download the document. 
• Document Processing Time: The time it takes for the browser to finish parsing the HTML code of a web page and construct the Document Object Model (DOM). The DOM is a hierarchical representation of the page's elements, which can be manipulated by JavaScript.

  Document processing time can be affected by a number of factors, including:

  • The size of the HTML code: Larger HTML files will take longer to parse.
  • The complexity of the HTML code: More complex HTML files will take longer to parse.
  • The performance of the browser: Faster browsers will be able to parse HTML code more quickly.
  • The presence of JavaScript: JavaScript files can add to the document processing time.

  Here are some tips for improving document processing time:

  • Use minified and compressed HTML code: Minified and compressed HTML code is smaller, which means it will take less time to parse.
  • Use a CDN: A CDN (Content Delivery Network) can deliver HTML code from servers that are closer to the user, which can improve document processing time.
  • Use a caching mechanism: A caching mechanism can store HTML code that has already been parsed, which can reduce the need to parse it again.
  • Optimize the JavaScript files: Optimizing JavaScript files can improve their performance and reduce the document processing time.

• Time to First Byte (TTFB): A metric that measures the time it takes for a web browser to receive the first byte of a response from a web server. This includes the time it takes to:
  • DNS lookup: The time it takes to resolve the domain name of the web server.
  • TCP connection establishment: The time it takes to establish a connection to the web server.
  • TLS handshake: The time it takes to establish a secure connection to the web server, if the request is made over HTTPS.
  • Request: The time it takes to send the request for the resource to the web server.

• DOM Ready Time: The time it takes for a web browser to finish parsing the HTML code of a web page and construct the Document Object Model (DOM). The DOM is a hierarchical representation of the page's elements, which can be manipulated by Javascript.
  

  The DOM Ready Time event is fired when the DOM is ready, but the page is not necessarily fully loaded yet. This means that images, CSS, and other resources may still be loading. However, the DOM Ready Time event is a good indication of how long it takes for a web page to become interactive.

  There are a number of factors that can affect DOM Ready Time, including the size and complexity of the HTML code, the speed of the user's internet connection, and the performance of the browser.

  DOM Ready Time is an important metric for measuring the performance of a web page. A short DOM Ready Time means that the page will be interactive more quickly, which can improve the user experience.

  Here are some tips for improving DOM Ready Time:

  • Use minified and compressed HTML, CSS, and JavaScript files.
  • Avoid using too many images or other large resources.
  • Use a CDN to deliver static resources.
  • Use a caching mechanism to store frequently accessed resources.

• Network Time: The time it takes for a web browser to fetch all of the resources that are needed to load a web page. This includes the time it takes to:
  • DNS lookup: The time it takes to resolve the domain name of the resources.
  • TCP connection establishment: The time it takes to establish a connection to the servers that host the resources.
  • TLS handshake: The time it takes to establish a secure connection to the servers, if the resources are hosted over HTTPS.
  • Request: The time it takes to send the requests for the resources to the servers.
  • Response: The time it takes to receive the responses from the servers, including the time it takes to download the resources.

• Rendering Time: The time it takes for a web browser to render a web page. This includes the time it takes to:
  • Parse the HTML code: The time it takes to parse the HTML code of the web page and construct the DOM.
  • Load the CSS and JavaScript files: The time it takes to load the CSS and JavaScript files that are needed to style and interact with the web page.
  • Render the images and other resources: The time it takes to render the images and other resources that are used on the web page.

There are a few reasons why DOM ready time can be high but document processing time can be low.

• The HTML code is large and complex. A large and complex HTML code can take longer to parse, even if it does not contain any JavaScript. This is because the browser has to process more information to create the DOM.
• The web page uses a lot of third-party resources. Third-party resources, such as images, CSS, and JavaScript files, can also add to the DOM ready time. This is because the browser has to wait for these resources to load before it can create the DOM.
• The web page is using a slow web server. If the web server is slow, it can take longer for the browser to download the HTML code and third-party resources. This can also increase the DOM ready time.

If your DOM ready time is high, but your document processing time is low, then you may need to optimize your HTML code to make it smaller and easier to parse.

If you access Realtime Transaction and double click on any URL you may encounter a message "Trace not available..."

Enabling tracing on End User Experience

1. Go to Server Analyzer > IntelliTrace > HTTP
2. Right click on the URL on which you want to enable detailed tracing and select "Add as a Key Business Transaction".
3. Add the URL to Key Business Transaction. You can directly visit Business Transactions > Configure Key Business Transactions and add the URL to Business Transaction Monitoring.
4. Go to Profiling > Configure Business Transactions  > Transaction Monitoring.
5. Enable Per-Transaction Monitoring.
6. Enable Transaction Tracing.

Once you have followed the above steps, restart the agent jvm.

Now you can visit the UEM > End User Experience Analyzer > Realtime Transactions and double click on the URL.

If you have added the URL as KBT, detailed trace will be displayed as shown in the following image.

Browser and Backend Server Views

Browsers and Servers tabs are similar to Transaction Summary view but displays performance data for each client browser type and by the backend servers processing transactions.

End Client running Processes Monitoring

End Client Process Monitoring provides running processes and resources utilized by each process on the end client machine where browser is running. This helps identify if the slowness is caused by some process running on End User's computer. End Client Process Monitoring is only supported on Windows and Internet Explorer (IE) end clients. End Client Process Monitoring requires permissions from the end user (or centrally configured by administrators) to allow running 'Microsoft Script Runtime'. If these permissions are not certrally configured then users are prompted on first visit to the pages with end client process monitoring enabled.

End Client Process Monitoring can be enabled for slow calls or all calls.