Agents Administration - Tests
 

Configuration of RUMRegionTest

This test Provides an aggregate of the experience of users from different geographic regions. If multiple users to a web site/web application are seeing slow page loads or error responses at around the same time, administrators can use this test to figure out if the problem is region-specific or not; if so, the test further pinpoints which exact region is impacted and why is the experience of users from that region poor - is the front end used by the users in this region inefficient? Is the WAN connection between the clients in this region and the backend server hosting the web site/web application latent? or is the problem with the backend? Detailed diagnostics provided by the test also point to the specific pages that are slow or threw JavScript errors.

The default parameters associated with this test are:

  • The TEST PERIOD list box helps the user to decide how often this test needs to be executed.

  • If the eG agent communicates with the RUM collector via a proxy, then specify the IP address/fully-qualified host name of the proxy server in the PROXYHOST text box. By default, this is set to none, indicating that the eG agent does not communicate with the collector via a proxy.

  • If the eG agent communicates with the RUM collector via a proxy, then specify the port in the PROXYPORT text box at which the proxy server listens for requests from the eG agent. By default, this is set to none, indicating that the eG agent does not communicate with the collector via a proxy.

  • If the eG agent communicates with the RUM collector via a proxy server, and if proxy server requires authentication, then specify valid credentials for authentication against PROXYUSERNAME and PROXYPASSWORD. If no proxy server is used or if the proxy server used does not require authentication, then set the PROXYUSERNAME and PROXYPASSWORD to none.

  • Confirm the PROXYPASSWORD by retyping it in the CONFIRM PASSWORD text box.

    • Note:

    If you reconfigure the test later to change the values of the PROXYUSERNAME, PROXYPASSWORD, and CONFIRM PASSWORD parameters, then such changes will be effected only if the eG remote agent monitoring the Real User Monitor component is restarted.

  • By default, the eG RUM monitors all requests to a managed web site. This is why, the DO YOU WANT TO LIMIT THE PAGE VIEWS? flag is set to No by default. However, in case of web sites that receive thousands of hits every day, monitoring each page view may add significantly to the overhead of the eG agent and may also increase the size of the eG database considerably. To reduce the strain on both the eG agent and the eG backend, you may want to restrict the monitoring scope of this test to a few page visits. To achieve this, first set this flag to Yes. This will invoke the MAXIMUM ALLOWED PAGE VISITS PER DAY option.

    By default, the MAXIMUM ALLOWED PAGE VISITS PER DAY is set to 100000. This implies that the test will consider only the first 100000 requests in a day for monitoring. All page visits beyond 100000 will by default be excluded from the test's monitoring purview. You can increase or decrease this limit, if you so need.

  • The URL SEGMENTS TO BE USED AS GROUPED URL parameter is applicable to the RUMGrpTest test alone. The RUMGrpTest test groups URLs based on the URL segments configured for monitoring and reports aggregated response time metrics for every group.

    Using this parameter, you can specify a comma-separated list of URL segment numbers based on which the pages are to be grouped.

    URL segments are the parts of a URL (after the base URL) or path delimited by slashes. So if you had the URL: http://www.eazykart.com/web/shopping/login.jsp, then http://www.eazykart.com will be the base URL or domain, /web will be the first URL segment, /shopping will be the second URL segment, and /login.jsp will be the third URL segment.

    By default, this parameter is set to 1,2. This default setting, when applied to the sample URL provided above, implies that the eG agent will aggregate request and response time metrics to all instrumented web pages (i.e., web pages with the code snippet) under the URL /web/shopping. Here, /web corresponds to the specification 1 (URL segment 1) and /shopping corresponds to the specification 2 (URL segment 2) in the default value 1,2. This in turn means that, if the web site consists of pages such as http://www.eazykart.com/web/shopping/products.jsp, http://www.eazykart.com/web/shopping/products/travel/bags.jsp, http://www.eazykart.com/web/shopping/payment.jsp, etc., then the eG agent will track the requests to and responses from all these web pages, aggregate the results, and present the aggregated metrics for the descriptor /web/shopping. This way, the test will create different page groups based on each of the second-level URL segments in the managed web site - eg., /web/movies, /web/travel, /web/reservations, /partner/contacts etc. - and will report aggregated metrics for each group so created.

    If you want, you can override the default setting by providing different URL segment numbers here. For instance, your specification can be just 2. In this case, for the URL http://www.eazykart.com/web/shopping/login.jsp, the test will report metrics for the descriptor /shopping. You can even set this parameter to 1,3. For a web site that contains URLs such as http://www.eazykart.com/web/shopping/products.jsp, http://www.eazykart.com/web/shopping/products/travel/bags.jsp, and http://www.eazykart.com/web/shopping/payment.jsp, this specification will result in the following descriptors: /web/products, /web/products.jsp, and /web/payment.jsp.

  • By default, this test does not track requests to the following URL patterns: *.js,*.css,*.jpeg,*.jpg,*.png, which are mentioned in the URL PATTERNS TO BE IGNORED FROM MONITORING text box. If required, you can remove one/more patterns from this default list, so that such patterns are monitored, or can append more patterns to this list in order to exclude them from monitoring. For instance, to additionally ignore URLs that end with .gif and .bmp when monitoring, you need to alter the default specification as follows: *.js,*.css,*.jpeg,*.jpg,*.png,*.gif,*.bmp

  • By default, this test alerts administrators to all Javascript errors that occur in the monitored web site/web application. This is why, this parameter is set to none by default. Sometimes however, administrators may not want to be notified when certain types of Javascript errors occur – this could be because such errors are harmless or are a normal occurrence in their environment. In such circumstances, you can instruct the eG agent to ignore these errors when monitoring. For this, specify the Java script error message to be ignored in the JAVASCRIPT ERRORS TO BE IGNORED text box, in the following format: <Javascript eror message>:<URL of the page/file where the message originated>.

    For instance, say that the login.html page in your web site runs a few Java scripts that throw Object expected errors, which you want the eG agent to ignore. In this case, your error specification can be as follows: Object expected:http://www.eazykart.com/web/login.html. Alternatively, you can provide only that text string with which the error message begins in your specification – eg., Object:http://www.eazykart.com/web/login.html. Moreover, instead of the complete URL, you can specify just the name of the HTML/jsp/aspx page in which the error is to be ignored - example: Object:login.html.

    Sometimes, the individual web pages in your web site may not run any Java script directly. Instead, these web pages may include links to Java script files that will run the Java script and return the output to the web pages. If you want the eG agent to ignore certain errors thrown by such a Javascript file, then your error pattern specification should include the URL of the Javascript file and not the web page that points to it. This is because, in this case, the file is where the error message originates. For instance, in the same example above, if the login.html page points to a validate.js file, and you want to ignore the Object expected errors that this JS file throws, your error pattern specification will either be, Object expected:validate.js, or Object:validate.js.

    Multiple error message-URL combinations can also be provided as a comma-separated list. The format of your specification will be: <Javascript error message 1>:<Originating URL 1>,<Javascript error message 2>:<Originating URL 2>,...

    For example, to ignore the Object expected and Uncaught TypeError errors in the login.html page, use the following specification:

    Object:login.html,Uncaught:login.html

    Likewise, to ignore the Object expected error in the login.html page and the Uncaught TypeError in the validate.js file, your specification will be:

    Object:login.html,Uncaught:validate.js

    If you want to ignore the Uncaught TypeError across all the pages of the web site, your specification will be as follows:

    Uncaught TypeError:All

    Note

    When specifying the to be ignored, take care of the following:

    • The error message should not contain any special characters - in particular, the ‘:’ (the colon) and the ‘,’ (the comma) characters should be avoided.

    • The case of the actual error message and the one specified as part of your error specification should match. This is because, the eG agent performs case-sensitive pattern matching.

  • By default, the MAXIMUM HEALTHY TRANSACTIONS IN DD parameter is set to 5 indicating that the detailed diagnosis of this test will collect and display metrics related to the top-5 normal/healthy page views, in terms of the Avg_Page_Load_Time. To identify the top 5, the eG agent sorts all healthy transactions in the ascending order of their Avg_Page_Load_Time, and picks the first 5 transactions from this sorted list for display in the DETAILED DIAGNOSIS page and for storing in the eG database.

    You can however, increase or decrease this value depending upon how many healthy transactions you want to see in your detailed diagnosis, and how well-tuned or well-sized the eG database is.

    If you do not want the detailed diagnosis to include any healthy transaction, set the value of this parameter to 0. To view all healthy transactions, set the value of this parameter to all.

  • By default, the MAXIMUM SLOW TRANSACTIONS IN DD parameter is set to 5 indicating that the detailed diagnosis of this test will display metrics related to all the top-5 slow transactions, in terms of the Avg_Page_Load_Time. To identify the top 5, the eG agent sorts all slow transactions in the descending order of their Avg_Page_Load_Time, and picks the first 5 transactions from this sorted list for display in the DETAILED DIAGNOSIS page and for storing in the eG database.

    You can however, increase or decrease this value depending upon how many slow transactions you want to see in your detailed diagnosis, and how well-tuned or well-sized the eG database is.

    If you do not want the detailed diagnosis to include any slow transaction, set the value of this parameter to 0. To view all slow transactions, set the value of this parameter to all.

  • By default, the MAXIMUM ERROR TRANSACTIONS IN DD parameter is set to 5, indicating that the detailed diagnosis of this test will display metrics related to the top-5 transactions that encountered JavaScript errors, based on when those errors occurred. To identify the top 5, the eG agent sorts all error transactions in the descending order of the date/time at which the errors occurred, and picks the first 5 transactions from this sorted list for display in the DETAILED DIAGNOSIS page and for storing in the eG database.

    You can however, increase or decrease this value depending upon how many error transactions you want to see in your detailed diagnosis, and how well-tuned or well-sized the eG database is.

    If you do not want the detailed diagnosis to include any slow transaction, set the value of this parameter to 0. To view all slow transactions, set the value of this parameter to all.

  • This test reports the count of slow page views and also pinpoints the pages that are slow. To determine whether/not a page is slow, this test uses the SLOW TRANSACTION CUTOFF parameter. By default, this parameter is set to 4000 millisecs (i.e., 4 seconds). This means that, if a page takes more than 4 seconds to load, this test will consider that page as a slow page by default. You can increase or decrease this SLOW TRANSACTION CUTOFF according to what is ‘slow’ and what is ‘normal’ in your environment.

  • eG RUM relies on the Navigation API to track page views and capture page load time. Sometimes, the Navigation API can incorrectly report abnormally high values for page load time. To ensure that the eG agent ignores beacons with such page load time values, you can configure in the PAGELOADTIME CUTOFF (MS) text box, the maximum value for page load time. By default, this is set to 3600000 (ms). This implies that by default, the eG agent will disregard all beacons that carry page load time values higher than 3600000 milliseconds. You can change this value to suit your environment.

  • This test reports the count of tolerating page views and also pinpoints the pages with tolerating page views. For the page view to be considered as a tolerating page view, this test uses the TOLERATING CUTOFF parameter. By default, this parameter is set to 16000 millisecs (i.e., 16 seconds). By default, this parameter should be 4 times the Slow Transaction Cutoff (Ms) parameter. This means that, if a page takes anywhere between 4 to 16 seconds to load, then, this test will consider that page as a page with tolerating page view by default. You can increase or decrease this Tolerating Cutoff according to what is ‘tolerating’, what is ‘slow’ and what is ‘normal’ in your environment.

  • By default, the eG RUM Dashboard displays details of base page views only. You can optionally include Ajax and/or iFrame views as well in the dashboard, by selecting the relevant options from the PAGE TYPES TO BE INCLUDED IN DASHBOARD.

  • The DD FREQUENCY refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.

  • By default, the SEND ZERO VALUES WHEN THERE IS NO TRAFFIC flag is set to No. This implies that, if there is no traffic to a monitored web site/web application - i.e., if all measures of this test return only the value 0 - then the eG agent will not report these metrics to the eG manager. This also means that, by default, users to the eG monitoring console will not know that there is no traffic to the web site/web application.

    You can however, ensure that users to the eG monitoring console are informed of the absence of any user activity on the web site/web application. For this, set this flag to Yes. If this is done, then the eG agent will report all the metrics of this test to the eG manager, despite the fact that their value is 0. These zero values will clearly indicate to users that there no traffic to the monitored web site/web application.

  • To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the DETAILED DIAGNOSIS capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

    The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

    • The eG manager license should allow the detailed diagnosis capability

    • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

  • If multiple components of the same component type are awaiting configuration, then an APPLY TO OTHER COMPONENTS check box will appear in this page. Clicking on this check box will allow you to apply the configuration to all/selected components of that type.

  • Once the necessary values have been provided, clicking on the UPDATE button will register the changes made.

When changing the configuration for specific servers, a “*” beside the text box corresponding to the parameter signifies that these values have to be manually configured by the user. The parameter values that require to be configured will typically be prefixed with a “$” or contain a series of “*”. A value of "none" in the parameter value indicates that the corresponding parameter value can be changed if required.