Citrix Web Application Protocols Test

Certain web protocols may require more processing power and time than others. When applications are accessed using such protocols, application performance is sure to be affected. To ensure peak application performance at all times, administrators need to quickly identify resource-intensive and least responsive protocols, and configure server size and firewall policies accordingly. This is where the Citrix Web Application Protocols test helps!

This test auto-discovers the web protocols used for accessing the web applications managed by the monitored ADC appliance. For each web protocol, the test reports the bandwidth usage and responsiveness of that web protocol, thus pointing administrators to bandwidth-intensive protocols and those that respond poorly to requests. For a slow protocol, the test additionally pinpoints the probable cause of the slowness - is the server hosting the application not configured right to support that protocol? or is the client or server network slow in processing that protocol?

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 web application protocol

Configurable parameters for the test
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: Login to the eG agent host. Edit the Netflow.Properties file in the <EG_AGENT_INSTALL_DIR>\NetFlow\config directory. In the file, look for the parameter, csv_file_retention_count. This is the parameter that governs the maximum number of CSV files that can be created in the auto_csv folder. By default, this parameter is set to 10. If you want to retain more number of CSV files at any given point in time, you can increase the value of this parameter. If you want to retain only a few CSV files, then decrease the value of this parameter. Next, look for the parameter, csv_max_flow_record_per_file. This is the parameter that governs the number of flow records that can be written to a single CSV. By default, this parameter is set to 99999. If you want a single file to accommodate more records, so that the creation of new CSVs is delayed, then increase the value of this parameter. On the other hand, if you want to reduce the capacity of a CSV file, so that new CSVs are quickly created, then decrease the value of this parameter. Finally, save the file.
Show Top N Protocols	By default, this is set to Yes. This means that, by default, the test will report metrics for only the top protocols (in terms of number of hits or bandwidth usage). In this case, only the top-N bandwidth-intensive or most-used protocols (depending upon the option chosen against the Show Top-N Protocols By parameter) will be the descriptors of this test. If you want the test to report metrics for all protocols, then set this flag to No.
Show Top N Protocols By	By default, this parameter is set to Hits. This means that, by default, the test will report metrics for only those protocols that have been used the most. If required, you can configure the test to report metrics for those protocols that are bandwidth-intensive. For that, set this parameter to Bandwidth.
Top N Protocols Limit	By default, this is set to 10. This denotes that the test will report metrics for the top-10 protocols (in terms of number of hits or bandwidth usage, depending upon the Show Top-N Protocols 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, by default, the detailed diagnosis of this test will display the details of only the top requests for a protocol (in terms of the number of hits or bandwidth usage, depending upon the Sort DD Data By setting). If you set this flag to No, then detailed diagnosis will provide the details of all requests
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 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: 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.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Hits	Indicates the number of requests to web applications that used this protocol.	Number	This is a good indicator of the load imposed by a protocol on web applications. Compare the value of this measure across protocols to know which protocol is most used. Use the detailed diagnosis of this measure to identify the bandwidth-intensive requests to the application that used a particular protocol, and requests that have often failed/resulted in error responses.
Bandwidth	Indicates the total amount of data used by this protocol.	KB	Compare the value of this measure across protocols to know which protocol is consuming bandwidth excessively.
Response time	Indicates the elapsed time between the end of a request that used this protocol and the beginning of a response from the application.	msecs	A high value for this measure indicates that the application is processing requests that use this protocol, slowly. If this measure reports an abnormally high value for a protocol, compare the value of the Server processing time, Client avg latency, and Server avg latency measures of that protocol to determine the reason for the slowness.
Server processing time	Indicates the elapsed time, from when the server starts to receive the first byte of a request that used this protocol until the ADC appliance receives the first byte to response.	msecs	A high value for this measure indicates that the web server is processing requests that used this protocol, slowly. If the Response time measure reports an abnormally high value for a protocol, then compare the value of this measure with that of the Client avg latency and Server avg latency measures of that protocol to determine what is causing the slowness – the poor processing power of the web server? a latent server network? or a slow client network?
Server avg latency	Indicates the average latency caused by the server network.	msecs	A high value for this measure indicates that the server network is latent. If the Response time measure reports an abnormally high value for a protocol, then compare the value of this measure with that of the Client avg latency and Server processing time measures of that protocol to determine what is causing the slowness – the poor processing power of the web server? a latent server network? or a slow client network?
Server max latency	Indicates the high watermark of server network latency.	msecs
Client avg latency	Indicates the average latency caused by the client network.	msecs	A high value for this measure indicates that the client network is latent. If the Response time measure reports an abnormally high value for a protocol, then compare the value of this measure with that of the Server avg latency and Server processing time measures of that protocol to determine what is causing the slowness – the poor processing power of the web server? a latent server network? or a slow client network?
Client max latency	Indicates the high watermark of client network latency.	msecs

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, request methods that took too long to be serviced by the application, and the probable cause for the poor responsiveness - did the server hosting the application take too long to process requests of that type? or is the slowness owing to a latent client or server network?

Figure 1 : The detailed diagnosis of the Hits measure reported by the Citrix Web Application Protocols test