User Experience Monitoring (UEM)¶
UEM, or User Experience Monitoring allows you to monitor the experience of your users, by getting data on how long the request took to render on the users browser and how long the request took to transfer to the client machine, over the network. This data is visible on the requests as a sub transaction.
The image above shows the UEM graph from a live server on the User Experience page.
Below is a sample image of the User Experience Graph with little data.
From this graph you can see four series :
- UEM - DB Time (ms) : Red
- This is the average database time for all request that track UEM data.
- UEM - WebRequest Time (ms) : Blue<
- This is the average web request time for all request that track UEM data.
- UEM - Time on Network (ms) : Orange
- This is the average network transfer time for UEM requests.
- UEM - Client Time (ms) : Green
- This is the average time that it took to render the page on the clients device.
Placing your mouse pointer on a data point within the graph will show a tool-tip with details about that sample, including :
- Date and time of the request
- UEM - DB Time ( Requests / sec )
- UEM - WebRequest Time (ms)
- UEM - Time on Network (ms)
- UEM - Client Time (ms)
When browsing the 1 Hour, 1 Day, and 1 Week activity graphs you are able to select time frames by using the slider under the graph. To pinpoint specific days, times and spikes your users experiences.
- 60 seconds at 1 second
- 1 Hours at 5 seconds
- 1 Day at 1 minute
- 1 Week at 1 hour
How UEM works¶
Information regarding the UEM Cookie¶
UEM requires the use of a cookie which is sent with all web requests to track the users page performance. It may be necessary to document that this cookie exists and is used for tracking performance. In order to comply with EU Legislation - see http://www.cookielaw.org/the-cookie-law/ - you 'may' be required to provide information to your users regarding what the cookie is used for, and then ask for consent from users for the right to store and retrieve information from their computer, tablet, or smartphone.
Session tracking with Spring The Spring Framework Spring Session Project includes several different implementations of session handling, which are tracked on this page. Spring boot applications are tracked using the spring.application.name property that can be set, usually with an application.properties file. Otherwise the default application name value will be used. For applications using the MongoDB and JDBC session repository implementations, FusionReactor currently does not track session expiry
Root session tracking in ColdFusion When tracking sessions in ColdFusion you will see a session with the name /root. This is caused by the way ColdFusion uses the J2EE sessions. When J2EE sessions are enabled in ColdFusion, the sessions are stored within the tomcat /root context.There is also then a ColdFusion session created that wraps this J2EE session. By default, ColdFusion sessions will expire based on a worker thread, but the J2EE sessions will expire based on time since last used. So the ColdFusion session can be destroyed by the worker thread, but the J2EE session will remain. For example, if a user comes back, a new ColdFusion session is created, but the same J2EE session will be used.
When using the UEM script in your web page it is best to put the FRAPI call as close to the end of the web page as possible. This is so that the time of server execution is not included in the client time.
It is safe to cache the FRAPI object to use for other FRAPI calls.
JSP Script Example¶
<%@ page import="com.intergral.fusionreactor.api.FRAPI"%>
<% FRAPI frapi = FRAPI.getInstance(); %>
// The main page content goes here
if(frapi != null)
CFML Script Example¶
FrapiClass = createObject("java","com.intergral.fusionreactor.api.FRAPI");
frapi = FrapiClass.getInstance();
In the case of ColdFusion/CFML, you could put this code into any single page. Or to cause it to be sent to all requests in a given application, you could put it in any sort of header or footer template which you may CFINCLUDE or may reference by any other form of explicit or implicit invocation. You could also put it in application.cfm or onrequestend.cfm, or in the onrequeststart or onrequestend method of application.cfc.
Convert static HTML to use UEM¶
It is not possible at this time to simply embed the UEM script into a static page such as a simple html page. However it is possible to convert the basic HTML page into a dynamic page with out making many changes.
If we have a page index.html that is a static page of links, but we want to monitor the UEM for this page. We have to convert this into a dynamic page (e.g. JSP or CFM) and add the UEM script call into the page.
Step 1 - Rename the file¶
First you will have to rename the index.html file to the index.jsp or index.cfm (depending on your application server).
Renaming a file on the file system can result in link errors if other pages depend on the extension. Please ensure that all links to the altered file also get updated to use the new extension!
Step 2 - Add the UEM script¶
Now edit the contents of the index.cfm file to include the UEM script call.
Step 3 - Done¶
That is all that is required you will now have a index.cfm file that should behave the same as it did before but will not be dynamically generated to include the UEM script.
Using UEM with an external web server¶
Just as FusionReactor can be used with an external web server, so also can UEM to work over IIS or Apache.
The available UEM EndPoint Filter, specified in the UEM Settings page, which indicates the extension to be used to map the request back to the application server which FusionReactor is running on.
Notice there is not actually any UEMJS.cfm file (in your web site, or in FusionReactor's files). Rather, FusionReactor responds with the script in response to a page of this name being requested.
If you have configured IIS / Apache security to require authentication for your web site, you must disable that authentication for the UEM scripts, as discussed in the following section.
To allow the UEM endpoints to be served while using IIS or Apache authentication, please follow these steps for your web server to disable authentication for these endpoints. After following these steps it should be possible to access the URL (for ColdFusion, as an example) http://localhost/fusionreactor.cfm/UEMJS.cfm, without authentication.
- In IIS, navigate to the web site in which you want to enable UEM monitoring (which has authentication enabled, which we want to disable for the UEM scripts)
- Create a virtual directory that matches the FusionReactor setting, Web Root, discussed above (by default, fusionreactor), Point the virtual directory to a blank directory
- Create blank files called UEM.cfm and UEMJS.cfm (where the .extension matches your UEM EndPoint Filter) and place them in that blank directory
- In IIS, click the 'Content View' button at the bottom of IIS, to view files in this virtual directory. You should see the two files you created.
- Right-click on the first of the two files, and select 'Features View'. Notice this will select just this file within the virtual directory, in the display on the left
- Double click the 'Authentication' Icon (notice we are not setting this at the virtual directory level, but just for the selected file)
- Disable all forms of authentication other than 'Anonymous Authentication', leaving this enabled.
- Repeat from step 5-7 for the other file.
Create a file called UEM.cfm and UEMJS.cfm (where the .cfm matches your UEM EndPoint Filter) and place them under the virtual directory that is used to authenticate FusionReactor (Web Root, discussed above by default, fusionreactor).
Edit the 'mod_jk.conf' file that was created by ColdFusion when setting up the connector
- Add a <Files> block for each file, see below ($FileName should be the file name UEM.cfm)
Allow from all