eG Help

Users today do not rely on their PCs alone to access web applications or consume web-based services. Users now work with a wide range of devices - from iPhones to iPads to Tablets - that allow quick, easy, and on-the-go access to the web. On any typical day therefore, a web site/web application may be bombarded with requests from a gamut of devices. Since the technology driving each of these devices is very distinct, there is a high likelihood that the experience of users may vary with the device. Insights into the user experience per device type can help administrators figure out whether the slowness experienced or errors encountered by users are owing to the device they are using, or due to other factors such as the network or the backend. The RUMDeviceTest test helps administrators with this!

This test automatically discovers the types of devices used to launch the target web site/web application and reports the average page load time per device type. The percentage of JavaScript errors encountered by the users of each device type is also reported. This way, the test rapidly pinpoints those device types, the users of which are experiencing problems when accessing the web site/web application. For every device type, the test also provides a breakup of the page load time, which clearly indicates where the bottleneck lies - is it with the device? the network? or the backend? Detailed diagnostics provided by the test lead administrators to the specific web pages that are slow. Error pages and the errors affecting them are also offered as part of the detailed diagnosis. Based on these inputs, administrators can either attempt to tweak the application to support the ‘unfriendly’ devices or add that device type to their list of incompatible devices.

By default, the eG agent can send a maximum of 50 million characters to the eG manager, when reporting detailed diagnostics for a test for a single measurement period. If this limit is exceeded by a test during a measurement period, then the detailed diagnostics reported by that test will be automatically truncated and the additional characters dropped. Moreover, a message to this effect will also be logged in the eG agent's error log. If such errors are logged frequently for a particular test, you may want to seriously consider increasing this character limit of the detailed metrics collected by that test. For this purpose, do the following:

Measurement	Description	Measurement Unit	Interpretation
Page_Requests	Indicates the total number of times pages in the web site/web application were viewed by users using this device type.	Number	This is a good measure of the traffic to your web site/web application from a given device type. A high number of page views from a single device type typically indicates how popular the device is. Sudden, but significant spikes in the page view count could be a cause for concern, as it could be owing to a malicious virus attack or an unscrupulous attempt to hack your web site/web application.
Apdex_Score	Indicates the apdex score of the web site/web application based on the experience of users using this device type.	Number	Apdex (Application Performance Index) is an open standard developed by an alliance of companies. It defines a standard method for reporting and comparing the performance of software applications in computing. Its purpose is to convert measurements into insights about user satisfaction, by specifying a uniform way to analyze and report on the degree to which measured performance meets user expectations. The Apdex method converts many measurements into one number on a uniform scale of 0-to-1 (0 = no users satisfied, 1 = all users satisfied). The resulting Apdex score is a numerical measure of user satisfaction with the performance of enterprise applications. This metric can be used to report on any source of end-user performance measurements for which a performance objective has been defined. The Apdex formula is: Apdext = (Satisfied Count + Tolerating Count / 2) / Total Samples This is nothing but the number of satisfied samples plus half of the tolerating samples plus none of the frustrated samples, divided by all the samples. A score of 1.0 means all responses were satisfactory. A score of 0.0 means none of the responses were satisfactory. Tolerating responses half satisfy a user. For example, if all responses are tolerating, then the Apdex score would be 0.50. Ideally therefore, the value of this measure should be 1.0. A value less than 1.0 indicates that the user experience with the web site/web application has been less than satisfactory.
Avg_Page_Load_Time	Indicates the average time taken by the pages in the web site/web application to load completely on the browser launched from this device.	ms	This is the average interval between the time that a user initiates a request and the completion of the page load of the response in the user's browser on this device. In the context of an Ajax request, it ends when the response has been completely processed. By comparing the value of this measure across device types, you will be able to tell if the page load time is significantly higher for any one browser. If so, then consider it as the first sign of a problem with that browser. Now, use the detailed diagnosis of this measure for the problematic browser to know which specific pages are slow in loading on that browser. Then, check the detailed diagnosis of the other browsers to determine whether/not any slowness has been observed in the same pages when accessed using those browsers. If not, then you can confirm that a problem exists in that one browser only. A device problem often manifests itself as a delay in DOM download, DOM processing, or page rendering. Therefore, once you zero-in on the problematic browser, check the values of the Avg_Dom_Download_Time, Avg_Dom_proc_Time and Avg_Page_Rendering_Time measures to ascertain where the browser is losing considerable time - when downloading the HTML document? Or when processing it? Or when rendering the page?
Unique_User_session	Indicates the number of distinct users who are currently accessing the web site/web application using this device type.	Number
Request_Per_Minute	Indicates the number of times the pages in the web site/web application were viewed per minute using this device type.	Number	This is a good indicator of the level of activity on the web site. An unusually high value for this measure may require investigation.
Percentage_Normal	Indicates the percentage of page views from this device type that delivered a satisfactory experience to users.	Percent	The value of this measure indicates the percentage of page views in which users have neither experienced any slowness, nor encountered any Javascript errors. Ideally, the value of this measure should be 100%. A value that is slightly less than 100% indicates that the user experience from this browser has not been up to the mark. A value less than 50% is indicative of a serious problem, where most of the page views from this browser are either slow or have encountered Javascript errors. Under such circumstances, to know what exactly is affecting the experience of users using that device, compare the value of the Percentage_Slow with that of the Percentage_Error for that device. This will reveal the reason for the poor user experience - slow pages? or Javascript errors? If slow pages are the problem, use the detailed diagnosis of the Slow_Requests measure of that device to know which pages are slow and why. If the slowness is indeed owing to the use of an incompatible device, then the detailed diagnostics will reveal a very high Avg_Dom_Ready_Time or Avg_Page_Rendering_Time for each of the slow pages. On the other hand, if the slowness is owing to a network or backend problem, then very high values will be registered for the Avg_Network_Time or Avg_Response_Avail_Time measures, as the case may be.
Percentage_Slow	Indicates the percentage of page views that are slow in loading on this device type.	Percent	Ideally, the value of this measure should be 0. A value over 50% implies that you are in a spot of bother, with over half of the page views being slow. Use the detailed diagnosis of the Slow_Requests measure to identify the slow pages and isolate the root-cause of the slowness - is it the device? the network? or the backend?
Percentage_Error	Indicates the percentage of page views from this device that have encountered JavaScript errors.	Percent	IIdeally, the value of this measure should be 0. A value over 50% implies that you are in a spot of bother, with over half of the page views from the device experiencing JavaScript errors. Use the detailed diagnosis of this measure to identify the error pages and to know what Javascript error has occurred in which page. This will greatly aid troubleshooting!
Satisfied_Requests	Indicates the number of times pages were viewed from this device without any slowness.	Number	A page view is considered to be slow when the average time taken to load that page exceeds the SLOW TRANSACTION CUTOFF configured for this test. If this SLOW TRANSACTION CUTOFF is not exceeded, then the page view is deemed to be ‘satisfactory’. To know which page views are satisfactory, use the detailed diagnosis of this measure. Ideally, the value of this measure should be the same as that of the Page_Requests measure. If not, then it indicates that one/more page views are slow - i.e., have violated the SLOW TRANSACTION CUTOFF. If the value of this measure is much lesser than the value of the Tolerated_Requests and the Frustrated_Requests, it is a clear indicator that the experience of users using this browser is below-par. In such a case, use the detailed diagnosis of the Tolerated_Requests and the Frustrated_Requests measures to know which pages are slow and why.
Slow_Requests	Indicates the number of page views from this device that were slow.	Number	A page view is considered to be slow when the average time taken to load that page exceeds the SLOW TRANSACTION CUTOFF configured for this test. Ideally, a page should load quickly. The value 0 is hence desired for this measure. If the value of this measure is high, it indicates that users frequently experienced slowness when accessing pages in the web site/web application. To know which page views are slow and why, use the detailed diagnosis of this measure.
Error_Requests	Indicates the number of times JavaScript errors occurred when accessing pages from this device.	Number	Ideally, the value of this measure should be 0. A high value indicates that many JavaScript errors are occurring when viewing pages in the web site/web application. Use the detailed diagnosis of this measure to identify the error pages and to know what Javascript error has occurred in which page. This will greatly aid troubleshooting!
Tolerated_Requests	Indicates the number of tolerating page views from this device type.	Number	If the Avg_Page_Load_Time of a page exceeds the SLOW TRANSACTION CUTTOFF configuration of this test, but is less than 4 times the SLOW TRANSACTION CUTOFF (i.e., < 4 * SLOW TRANSACTION CUTOFF), then such a page view is considered to be a Tolerating page view. Ideally, the value of this measure should be 0. A value higher than that of the Satisfied_Requests measure is a cause for concern, as it implies that the overall user experience from this browser is less than satisfactory. To know which pages are contributing to this sub-par experience, use the detailed diagnosis of this measure. The detailed metrics will also enable you to accurately isolate what is causing the tolerating page views - a problem with the device network? or backend?
Frustrated_Requests	Indicates the number of frustrated page views from this device type.	Number	If the Avg_Page_Load_Time of a page is over 4 times the SLOW TRANSACTION CUTTOFF configuration of this test (i.e., > 4 * SLOW TRANSACTION CUTOFF), then such a page view is considered to be a Frustrated page view. Ideally, the value of this measure should be 0. A value higher than that of the Satisfied_Requests measure is a cause for concern, as it implies that the experience of users using this browser has been less than satisfactory. To know which pages are contributing to this sub-par experience, use the detailed diagnosis of this measure. The detailed metrics will also enable you to accurately isolate what is causing the frustrated page views - a problem with the device network? or backend?
Avg_Front_End_Time	Indicates the interval between the arrival of the first byte of text response and the completion of the response page rendering by the browser on this device type.	ms	In a typical page loading process, the Avg_Front_End_Time denotes the time from the responseStart event to the loadEventEnd. This process includes document downloading, processing, and page rendering. This time is therefore the sum of the Avg_Dom_Ready_Time and the Avg_Page_Rendering_Time. If the Avg_Page_Load_Time of the web site/web application exceeds its threshold, then you may want to compare the value of this measure with that of the Avg_Network_Time and Avg_Response_Avail_Time to zoom into the source of the slowness – is it the device? the network? or the backend? If the Avg_Front_End_Time is the highest, it indicates that the problem is with the device - this can be attributed to a slowdown in page rendering or in DOM building. To nail the precise cause of the slowdown, compare the values of the Avg_Dom_proc_Time, Avg_Dom_Download_Time, and the Avg_Page_Rendering_Time measures. On the basis of this comparison, you will be able to tell whether the slowness occurred when downloading the document, when processing it, or when rendering the response page in the browser on this device.
Avg_Page_Rendering_Time	Indicates the time taken to complete the download of remaining resources, including images, and to finish rendering the page in the browser on this device type.	ms	A high value of this measure indicates that the web site/web application is taking too long to render the page in the browser. This can adversely impact the Avg_Front_End_Time, which in turn can prolong the Avg_Page_Load_Time. Ideally therefore, the value of this measure should be low.
Avg_Dom_Ready_Time	Indicates the time taken by the browser on this device type to make the complete HTML document (DOM) available for JavaScript to apply rendering logic.	ms	The value of this measure is the sum of the Avg_Dom_Download_Time and the Avg_Dom_proc_Time measures. If the value of this measure is very high, then you may want to compare the Avg_Dom_Download_Time and the Avg_Dom_proc_Time measures to figure out what is delaying DOM building - downloading? Or processing? A high value for this measure can adversely impact the Avg_Front_End_Time, which in turn can prolong the Avg_Page_Load_Time. Ideally therefore, the value of this measure should be low.
Avg_Dom_Download_Time	Indicates the time taken to download the complete HTML document on the browser on this device type.	ms	Higher the download time of the document, longer will be the time taken to make the document available for page rendering. As a result, the overall user experience will be affected when the device type is used! This is why, a low value is desired for this measure at all times.
Avg_Dom_proc_Time	Indicates the time taken by the browser on this device type to build the Document Object Model (DOM) and make it available for JavaScript to apply rendering logic.	ms	An unusually high value for this measure is a clear indicator that DOM building is taking longer than normal. In consequence, page rendering will be delayed, thus adversely impacting user experience when this device is used. Ideally therefore, the value of this measure should be low.
Avg_First_Byte_Time	Indicates the interval between the time that a user initiates a request and the time that the browser on this device type receives the first response byte. In the context of an Ajax request, this is the interval between the Ajax request dispatch and the time that the browser on this device type receives the first response byte.	ms	The Avg_First_Byte_Time is the time that elapsed between navigationStart and responseStart. The value of this measure is also the sum of Avg_Response_Avail_Time, Avg_DNS_Time, and Avg_TCP_Time. This means that an abnormal increase in any of the above-mentioned time values will increase the value of this measure. If the first response byte from the target web site/web application is itself received slowly, it is bound to have a cascading effect on all events that follow - such as, document downloading, processing, and page rendering. Ultimately, this will impact the page load time as seen by end-users. This is why, if the Avg_First_Byte_Time violates its threshold, administrators need to instantly switch to the troubleshooting mode and rapidly isolate what is causing it - is DNS lookup taking a long time? is the network connection to the web site/web application latent? or is the web server/web application server hosting the web site slow in processing requests? By comparing the values of the Avg_Response_Avail_Time, Avg_DNS_Time, and Avg_TCP_Time measures, administrators can swiftly and accurately figure out the exact reason why there was a delay in receiving the first response byte. If this comparison reveals that the Avg_DNS_Time is the highest, it implies that domain name resolution by the DNS server is taking a long time and impacting responsiveness. If the Avg_TCP_Time is found to be the culprit, then blame the network connection for delaying the transmission of the response byte. If the Avg_Response_Avail_Time is higher than the rest, you can be rest assured that the source of the problem lies with the server hosting the web site/web application.
Avg_Response_Avail_Time	Indicates the interval between the start of processing of a request on the browser on this device type to when this device type receives the response.	ms	The Avg_Response_Avail_Time is the time spent between the requestStart event and responseStart event. Ideally, a low value is desired for this measure, as high values will certainly hurt the Apdex_Score of the web site/web application. The key factor that can influence the value of this measure is the request processing ability of the web server/web application server that is hosting the web site/web application being monitored. Any slowdown in the backend web server/web application server - caused by the lack of adequate processing power in or improper configuration of the backend server - can significantly delay request processing by the server. In its aftermath, the Avg_Response_Avail_Time will increase, leaving users with an unsatisfactory experience with the web site/web application.
Avg_Network_Time	Indicates the elapsed time since a user using this device type initiates a request and the start of fetching the response document from the server or application.	ms	The time spent between navigationStart and requestStart makes up the Avg_Network_Time. This includes the time to perform DNS lookups and the time to establish a TCP connection with the server. In other words, the value of this measure is nothing but the sum of the Avg_DNS_Time and Avg_TCP_Time measures. Ideally, the value of this measure should be low. A very high value will often end up delaying page loading and damaging the quality of the web site service. In the event that the server connection time is high therefore, simply compare the values of the Avg_DNS_Time, and Avg_TCP_Time measures to know to what this delay can be attributed - a delay in domain name resolution? Or a poor network connection to the server?
Avg_DNS_Time	Indicates the time taken by this device type to perform the domain lookup for connecting to the web site/web application.	ms	A high value for this measure will not only affect DNS lookup, but will also impact the Avg_Network_Time and Avg_Page_Load_Time of the web site/web application. This naturally will have a disastrous effect on user experience.
Avg_TCP_Time	Indicates the time taken by this device type to establish a TCP connection with the server.	ms	A bad network connection between the browser client and the server can delay TCP connections to the server As a result, the Avg_Network_Time too will increase, thus impacting page load time and overall user experience with the web site/web application.