|
Default Parameters for DOTNETMonitorTest
This test effortlessly measures the performance of each transaction to a web site on a IIS web server, highlights transactions that are under-performing, and takes administrators close to the root-cause of poor transaction performance.
This page depicts the default parameters that need to be configured for the DOTNETMonitorTest test.
Specify the name of the web site on the target IIS web server for which transaction monitoring is to be performed in the WEBSITE NAME text box.
Note:
If this test is configured with a web site name, then all other web site-related tests of the target IIS web server will report metrics for this web site only.
By default, the HEALTHY URL TRACE flag is set to No. This means that eG Enterprise will not collect detailed diagnostics for those transactions that are healthy. If you want to enable the detailed diagnosis capability for healthy transactions as well, then set this flag to Yes.
The MAX HEALTHY URLS PER TEST PERIOD parameter is applicable only if the HEALTHY URL TRACE flag is set to ‘Yes’. Here, specify the number of top-n transactions that should be listed in the detailed diagnosis of the Healthy transactions measure, every time the test runs. By default, this is set to 50, indicating that the detailed diagnosis of the Healthy transactions measure will by default list the top-50 transactions, arranged in the descending order of their response times.
In the MAX SLOW URLS PER TEST PERIOD text box, specify the number of top-n transactions that should be listed in the detailed diagnosis of the Slow transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Slow transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.
In the MAX STALLED URLS PER TEST PERIOD text box, specify the number of top-n transactions that should be listed in the detailed diagnosis of the Stalled transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Stalled transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.
In the MAX ERROR URLS PER TEST PERIOD text box, specify the number of top-n transactions that should be listed in the detailed diagnosis of the Error transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Error transactions measure will by default list the top-10 transactions, in terms of the number of errors they encountered.
From the detailed diagnosis of slow/stalled/error transactions, you can drill down and perform deep execution analysis of a particular transaction. In this drill-down, the methods invoked by that slow/stalled/error transaction are listed in the order in which the transaction calls the methods. By configuring the METHOD EXECUTION CUTOFF parameter, you can make sure that methods that have been executing for a duration greater the specified cutoff are alone listed when performing execution analysis. For instance, if you specify 5 here, then the Execution Analysis window for a slow/stalled/error transaction will list only those methods that have been executing for over 5 milliseconds. This way, you get to focus on only those methods that could have caused the slowness, without being distracted by inconsequential methods. By default, the value of this parameter is set to 250 ms.
Typically, from the detailed diagnosis of a slow/stalled/error transaction to a web site, you can drill down to view the SQL queries (if any) executed by that transaction from that node and the execution time of each query. By configuring a SQL EXECUTION CUTOFF, you can make sure that queries that have been executing for a duration greater the specified cutoff are alone listed when performing query analysis. For instance, if you specify 5 here, then for a slow/stalled/error transaction, the SQL Queries window will display only those queries that have been executing for over 5 milliseconds. This way, you get to focus on only those queries that could have contributed to the slowness. By default, the value of this parameter is set to 10 ms.
This test groups URLs according to the ‘URL Segments’ specification. These grouped URLs will be the descriptors of the test. For each grouped URL, response time metrics will be aggregated across all transaction URLs in that group and reported.
When monitoring web sites/web applications to which the transaction volume is normally high, this test may report metrics for hundreds of descriptors. If all these descriptors are listed in the Layers tab page of the eG monitoring console, it will certainly clutter the display. To avoid this, by default, the test displays metrics for a maximum of 50 descriptors - i.e., 50 grouped URLs alone - in the eG monitoring console, during every measure period. This is why, the MAX GROUPED URLS PER MEASURE PERIOD parameter is set to 50 by default.
To determine which 50 grouped URLs should be displayed in the eG monitoring console, the eG BTM follows the below-mentioned logic:
Top priority is reserved for URL groups with error transactions. This means that eG BTM first scans URL groups for error transactions. If error transactions are found in 50 URL groups, then eG BTM computes the aggregated response time of each of the 50 groups, sorts the error groups in the descending order of their response time, and displays all these 50 groups alone as the descriptors of this test, in the sorted order. On the other hand, if error transactions are found in only one / a few URL groups - say, only 20 URL groups - then, eG BTM will first arrange these 20 grouped URLs in the descending order of their response time. It will then compute the aggregated response time of the transactions in each of the other groups (i.e., the error-free groups) that were auto-discovered during the same measure period. These other groups are then arranged in the descending order of the aggregated response time of their transactions. Once this is done, eG BTM will then pick the top-30 grouped URLs from this sorted list.
In this case, when displaying the descriptors of this test in the Layers tab page, the 20 error groups are first displayed (in the descending order of their response time), followed by the 30 ‘error-free’ groups (also in the descending order of their response time).
At any given point in time, you can increase/decrease the maximum number of descriptors this test should support by modifying the value of the MAX GROUPED URLS PER MEASURE PERIOD parameter.
Typically, from the detailed diagnosis of a slow/stalled/error transaction to a web site, you can drill down to view the SQL queries (if any) executed by that transaction from that node and the execution time of each query. By default, eG picks the first 500 SQL queries executed by the transaction, compares the execution time of each query with the SQL EXECUTION CUTOFF configured for this test, and displays only those queries with an execution time that is higher than the configured cutoff. This is why, the ‘MAX SQL QUERIES PER TRANSACTION’ parameter is set to 500 by default.
To improve agent performance, you may want the SQL EXECUTION CUTOFF to be compared with the execution time of a less number of queries - say, 200 queries. Similary, to increase the probability of capturing more number of long-running queries, you may want the SQL EXECUTION CUTOFF to be compared with the execution time of a large number of queries - say, 1000 queries. For this, you just need to modify the ‘MAX SQL QUERIES PER TRANSACTION’ specification to suit your purpose.
By default, this test does not track requests to the following URL patterns:
*.ttf, *.otf, *.woff, *.woff2, *.eot, *.cff, *.afm, *.lwfn, *.ffil, *.fon, *.pfm, *.pfb, *.std, *.pro, *.xsf, *.jpg, *.jpeg, *.jpe, *.jif, *.jfif, *.jfi, *.jp2, *.j2k, *.jpf, *.jpx, *.jpm, *.jxr, *.hdp, *.wdp, *.mj2, *.webp, *.gif, *.png, *.apng, *.mng, *.tiff, *.tif, *.xbm, *.bmp, *.dib, *.svg, *.svgz, *.mpg, *.mpeg, *.mpeg2, *.avi, *.wmv, *.mov, *.rm, *.ram, *.swf, *.flv, *.ogg, *.webm, *.mp4, *.ts, *.mid, *.midi, *.rm, *.ram, *.wma, *.aac, *.wav, *.ogg, *.mp3, *.mp4, *.css, *.js, *.ico|/egurkha*
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.
An HTTP cookie is a small piece of data sent from a website and stored on the user's computer by the user's web browser while the user is browsing. Most commonly, cookies are used to provide a way for users to record items they want to purchase as they navigate throughout a website (a virtual “shopping cart” or “shopping basket”). To keep track of which user is assigned to which shopping cart, the server sends a cookie to the client that contains a unique session identifier (typically, a long string of random letters and numbers). Because cookies are sent to the server with every request the client makes, that session identifier will be sent back to the server every time the user visits a new page on the website, which lets the server know which shopping cart to display to the user. Another popular use of cookies is for logging into websites. When the user visits a website's login page, the web server typically sends the client a cookie containing a unique session identifier. When the user successfully logs in, the server remembers that that particular session identifier has been authenticated, and grants the user access to its services. If you want to view and analyze the useful information that is stored in such HTTP response cookies that a web server sends, then set this flag to Yes. By default, the SHOW COOKIES flag is set to No, indicating that cookie information is not reported by default as part of detailed diagnostics.
HTTP headers allow the client and the server to pass additional information with the request or the response. A request header is a header that contains more information about the resource to be fetched or about the client itself. If you want the additional information stored in a request header to be displayed as part of detailed diagnostics, then set this flag to Yes. By default, the SHOW HEADERS flag is set to No indicating that request headers are not displayed by default in the detailed diagnosis.
This test groups transaction URLs based on the URL segments count configured for monitoring and reports aggregated response time metrics for every group. Using this parameter, you can specify the number of URL segments based on which the transactions 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/sportsgear/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 /sportsgear will be the third URL segment, and /login.jsp will be the fourth URL segment. By default, the URL SEGMENTS parameter is set to 3. This default setting, when applied to the sample URL provided above, implies that the eG agent will aggregate response time metrics to all transaction URLs under /web/shopping/sportsgear. Note that the base URL or domain will not be considered when counting URL segments. This in turn means that, if a web site receives transaction requests for the URLs such as http://www.eazykart.com/web/shopping/sportsgear/login.jsp, http://www.eazykart.com/web/shopping/sportsgear/jerseys.jsp, http://www.eazykart.com/web/shopping/sportsgear/shoes.jsp, http://www.eazykart.com/web/shopping/sportsgear/gloves.jsp, etc., then the eG agent will track the requests and responses for all these URLs, aggregate the results, and present the aggregated metrics for the descriptor /web/shopping/sportsgear. This way, the test will create different transaction groups based on each of the third-level URL segments - eg. /web/shopping/weddings, /web/shopping/holiday, /web/shopping/gifts etc. - and will report aggregated metrics for each group so created.
If you want, you can override the default setting by providing a different URL segment number 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 web/shopping.
If eG BTM finds that one/more slow database queries are responsible for the slowness that users are experiencing with a transaction, then you can drill-down from the cross application transaction topology of that transaction to view the slow SQL queries run by that transaction. This way, you can accurately isolate the root-cause of the slowness. By default, if any of these queries include confidential information such as passwords, then eG Enterprise will mask the passwords in the query using the ‘?’ (question mark) character. This way, eG Enterprise protects your business-critical data from abuse by intruders. Accordingly, the MASK SQL flag is set to Yes by default. For security reasons, we recommend that you do not change the default status of this flag. However, for some reason, if you want the password to be visible in clear text in the SQL queries displayed as part of the detailed analytics, then you can unmask the password by setting this flag to No.
The detailed diagnosis of this test lists the URLs of the problematic transactions to the target web site/application. Alongside the URLs, the IP address of the client from which each transaction was initiated is also displayed. By default, this client IP address - whether it is a public IP or a private IP - is masked by replacing the last octet with a 0 - i.e., the IP address 192.168.10.90 will by default be displayed as 192.168.10.0 in the detailed diagnosis. This is done to secure the target web site/application from malicious attacks. This is why, the MASK PUBLIC IP and Mask Private IP flags are set to Yes by default. For security reasons, we recommend that you do not change the default status of these flags.However, for some reason, if you want the full client IP address to be displayed in detailed diagnosis, then you can set both the flags to No.
The detailed diagnosis of this test lists the URLs of the problematic transactions to the target web site/application, so that administrators can accurately identify which specific transactions are adversely impacting user experience with the target web site/application. The URLs so displayed may sometimes include parameters/arguments that may be required by the corresponding transaction to execute. Sometimes, these parameters could carry sensitive information such as passwords. If any URL takes a password as a parameter/argument, then by default, this password is masked in the detailed diagnosis using the ‘?’ (question mark) character. This is done to secure the target web site/application from malicious attacks. This is why, the MASK URL PARAMS flag is set to Yes by default. For security reasons, we recommend that you do not change the default status of these flags. However, for some reason, if you want the password to be visible in clear text in the URLs in detailed diagnosis, then you can unmask the password by setting this flag to No.
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.
When changing default configurations of tests, the values with “$” indicate variables that will be replaced by the eG system according to the specific server being managed - for instance, $hostName is the host/nickname of the target host, $port is the port number of the server being monitored. E.g., for a server xyz:80, $hostName will be changed automatically by the eG manager to “xyz*” and $port will be changed to “80” when configuring a test.
|