Citrix Web URLs Test
If traffic to a web application is found to be bandwidth-intensive, administrators may instantly want to know which specific URL in that application is actually hogging the bandwidth resources. Administrators may later want to block access to these URLs, so as to conserve bandwidth. Likewise, if user experience with a web application deteriorates, administrators may want to swiftly check the responsiveness of each URL requested by the user, to identify which URL is adversely impacting the user experience and why. The Citrix Web URLs test helps administrators with this. This test automatically discovers the URLs accessed by users and reports the number of requests received and bandwidth used per URL. This way, the test pinpoints those URLs that are accessed frequently and the ones that generate bandwidth-intensive web traffic. Additionally, the test also reports the page load time and render time of every URL, so that, when a slowdown occurs, administrators can instantly identify the URL that resulted in a slow response and where the slowdown occurred – when the requested page was loaded? Or when it was rendered by the client?
Target of the test : An AppFlow-enabled ADC appliance
Agent deploying the test : A remote agent
Outputs of the test : One set of results for every URL that was accessed
Parameter | Description |
Test period |
How often should the test be executed. It is recommended that you set the test period to 5 minutes. This is because, the eG AppFlow Collector is capable of capturing and aggregating AppFlow data related to the last 5 minutes only. |
Host |
The host for which the test is to be configured. |
Cluster IPs |
This parameter applies only if the ADC appliance being monitored is part of a ADC cluster. In this case, configure this parameter with a comma-separated list of IP addresses of all other nodes in that cluster. If the monitored ADC appliance is down/unreachable, then the eG AppFlow Collector uses the Cluster IPs configuration to figure out which other node in the cluster it should connect to for pulling AppFlow statistics. Typically, the collector attempts to connect to every IP address that is configured against Cluster IPs, in the same sequence in which they are specified. Metrics are pulled from the first cluster node that the collector successfully establishes a connection with. |
Enable Logs |
This flag is set to No by default. This means that, by default, the eG agent does not create AppFlow logs. You can set this flag to Yes to enable AppFlow logging. If this is done, then the eG agent automatically writes the raw AppFlow records it reads from the collector into individual CSV files. These CSV files are stored in the <EG_AGENT_INSTALL_DIR>\NetFlow\data\<IP_of_Monitored_ADC>\webappflow\actual_csv folder on the eG agent host. These CSV files provide administrators with granular insights into the web appflows, thereby enabling effective troubleshooting. Note: By default, the eG agent creates a maximum of 10 CSV files in the actual_csv folder. Beyond this point, the older CSV files will be automatically deleted by the eG agent to accommodate new files with current data. Likewise, a single CSV file can by default contain a maximum of 99999 records only. If the records to be written exceed this default value, then the eG agent automatically creates another CSV file to write the data. If required, you can overwrite these default settings. For this, do the following:
|
Show Top N URLs |
By default, this is set to Yes. This means that, by default, the test will report metrics for only the top URLs (in terms of number of hits or bandwidth usage). In this case, only the top-N bandwidth-intensive or most-accessed URLs (depending upon the option chosen against the Show Top N URLs By parameter) will be the descriptors of this test. If you want the test to report metrics for all URLs, then set this flag to No. |
Show Top N URLs By |
By default, this parameter is set to Hits. This means that, by default, the test will report metrics for only those URLs that have received the maximum number of hits. If required, you can configure the test to report metrics for those URLs that are bandwidth-intensive. For that, set this parameter to Bandwidth. |
Top N URLs Limit |
By default, this is set to 10. This denotes that the test will report metrics for the top-10 URLs (in terms of number of hits or bandwidth usage, depending upon the Show Top N URLs By parameter setting) only. You can change the 'N' in top-N by specifying a higher or a lower value here. |
Show Top N in DD |
By default, this flag is set to Yes. This indicates that the detailed diagnosis of this test will display the details of only the top requests for the URL (in terms of the number of hits or bandwidth usage, depending upon the Sort DD Data By setting), by default. If you set this flag to No, then detailed diagnosis will provide the details of all URLs. |
Sort DD Data By |
By default, this test sorts the detailed diagnostics it reports in the descending order of those HTTP request method:response status pairs that have seen the maximum hits. Accordingly, the Hits option is by default chosen against this parameter. Detailed diagnosis so sorted will point you to those requests that frequently returned error responses. If required, you can sort the detailed diagnostics in the descending order of bandwidth usage, so you can quickly identify those application requests that resulted in bandwidth-intensive responses. For this, choose the Bandwidth option against this parameter. |
Top N DD Limit |
This parameter applies only if the Show Top N in DD flag is set to 'Yes'. By default, this parameter is set to 10, indicating that the detailed diagnostics will report the top-10 HTTP request method:response status pairs (in terms of the number of hits or bandwidth usage, depending upon the Sort DD Data By setting). You can change the 'N' in Top N by specifying any number of your choice in this text box. |
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. |
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise 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:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Hits |
Indicates the number of requests received by this web URL. |
Number |
This is a good indicator of how popular a URL is. Compare the value of this measure across web URLs to know which application is the most popular. Use the detailed diagnosis of this measure to identify the bandwidth-intensive requests to the URL and requests that have often failed/resulted in error responses. |
Bandwidth |
Indicates the total amount of data received by this web URL. |
KB |
Compare the value of this measure across URLs to know which URL is consuming bandwidth excessively. |
Avg load time |
Indicates the elapsed time, from when the browser starts to receive the first byte of a response until the user starts to interact with the page. At this stage, some of the page content might not yet have been loaded. |
msecs |
A high value for this measure is a cause for concern as it indicates that the requested web page is taking too long to load. In the event of a slowdown, you may want to compare the value of this measure with that of the Avg render time measure to accurately determine the reason for the slowness – is it because of a delay in page loading? Or page rendering? |
Avg render time |
Indicates the elapsed time, from when the browser starts to receive the first byte of a response until either all page content has been rendered or the page load action has timed out. |
msecs |
A high value for this measure indicates that the client is having problems rendering the requested pages. In the event of a slowdown, you may want to compare the value of this measure with that of the Avg load time measure to accurately determine the reason for the slowness – is it because of a delay in page loading? Or page rendering? |
The detailed diagnosis of the Hits measure groups application requests on the basis of the HTTP request method and response status of the requests. For each unique HTTP request method:response status pair, the detailed diagnosis reveals the client from which the requests were received, the OS of the client, the device used for sending the requests, and the web server to which the requests were sent. Additionally, the detailed diagnostics also report the number of hits, bandwidth usage, and responsiveness of each HTTP request method:response status pair. In the process, the test points to request methods that often resulted in error responses. Additionally, these detailed metrics will help you identify times when the web page (URL) requested took too long to load or was too slow to be rendered.
Figure 1 : The detailed diagnosis of the Hits measure reported by the Citrix Web URLs test