Web Clients Test

When encountered by a request overload on a web server, administrators must quickly identify the client that could have contributed to that load. Also, when users connecting from a specific client complain of slowness, administrators should be able to swiftly zero-in on the root-cause of that slowness, so that the problem can be resolved before user productivity is impacted. The Web Clients test helps in both accounts! This test tracks requests from every client connecting to the web servers managed by a NetScaler appliance, and reports the requests count, bandwidth usage, page rendering time, and the network latency for each client. From these metrics, administrators can easily infer which client is imposing the maximum load on the web servers. Moreover, if help desk receives frequent complaints of slowness from users connecting from a particular client, then administrators can use the metrics reported by this test to isolate the source of the delay – is it because the client is unable to render the response pages quickly? is it because of a latent client network? or is it owing to a contention for bandwidth resources?

Target of the test : Citrix NetScaler Web Insight

Agent deploying the test : A remote agent

Outputs of the test : One set of results for every client that fulfills the condition configured using the show by and show above limit parameters

Configurable parameters for the test
  1. 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 Nitro API using which the eG agent collects metrics from Web Insight, is capable of capturing only the performance data related to the last 5 minutes.
  2. Host - The host for which the test is to be configured.
  3. insight username, insight password, and confirm password -  To connect to Web Insight and collect the metrics it captures, the eG agent needs to be configured with the credentials of a user with read-only permissions to Web Insight. Type the name of this user against insight username and the password of this user against insight password. Then, confirm the password by retyping it in the confirm password text box.
  4. ssl – By default, Web Insight is not SSL-enabled. This is why, this flag is set to No by default. If it is SSL-enabled, then change this flag to Yes.
  5. show by and show above limit – Not all clients interacting with a web server may be worth monitoring. Some clients may be seldom used and hence may not require monitoring; some other clients may rarely encounter any slowdowns, and hence can be ignored when monitoring. Administrators may want to exclude such clients from monitoring, so that the strain on the eG agent is reduced. From the show by drop-down, you can pick the criterion based on which a client’s ‘monitoring worth’ is to be evaluated. The options here are: Render time, Requests, and All. If the Render time option is chosen from the show by list, then the test will monitor only those clients for which the Render time measure of this test registers a value equal to or above the value specified against show above limit. If the Requests option is chosen from the show by list, then the test will monitor only those clients for which the Requests measure of this test registers a value equal to or above the value specified against show above limit. By default, the show above limit is set to 30; this implies that:

    • If show by is set to Render time, then this test will monitor only those clients that report a value of 30 msecs or above for the Render time measure;
    • If show by is set to Requests, then this test will monitor only those clients that send at least 30 requests to the web servers;

    On the other hand, if you want to monitor all clients that communicate with the web server, regardless of the render time or request count, then select the All option from the show by list. In this case, the show above limit setting will be disregarded.

  6. 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.
  7. 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.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Requests:

Indicates the number of requests received from this client.

Number

In the event of an overload condition, you can compare the value of this measure across clients to know which client is overloading the servers.  

Use the detailed diagnosis of this measure to know which servers this client is accessing and which NetScaler manages the web traffic generated by this client.

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 by this client or the page load action has timed out.

msecs

A high value for this measure is a cause for concern as it indicates that the client is delaying page rendering.

In the event of a slowdown, you can compare the value of this measure with that of the Client network latency measure to zero-in on the root-cause of the slowdown - is it because the client is unable to render the response pages quickly? or is it because of a latent client network?

Client network latency:

Indicates the latency caused by the client-side network.

msecs

A high value for this measure is a cause for concern as it indicates that a bottleneck in the client-side network.

In the event of a slowdown, you can compare the value of this measure with that of the Render time measure to zero-in on the root-cause of the slowdown - is it because the client is unable to render the response pages quickly? or is it because of a latent client network?

Bandwidth:

Indicates the total amount of data received from this client.

KB

Compare the value of this measure across clients to know which client is hogging the bandwidth.

In the event of a slowdown, you can use the value of this measure to figure out if the lack of adequate bandwidth is what is slowing down user accesses from this client.

Cache hits:

Indicates the number of requests from this client that were serviced by the cache.

Number

If the value of this measure is the same as that of the Hits measure, it implies that all requests from the client were serviced by the cache. This is indicative of optimal cache size and usage. On the other hand, if the value of this measure is much lower than that of the Hits measure, it could indicate improper cache sizing and ineffective cache usage.

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.

Cache miss:

Indicates the number of requests from this client that were not serviced by the cache.

Number

Ideally, the value of this measure should be 0 or at least, very low. If the value is the same as that of the Hits measure, it could indicate improper cache sizing and ineffective cache usage.

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.

Cache hit ratio:

Indicates the percentage of requests from this client that were serviced by the cache.

Percent

Ideally, the value of this measure should be > 80%. A low hit ratio on the other hand indicates that a majority of web requests were serviced by the origin server and not the cache server. This can significantly increase request processing time and related overheads.

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.

Cache bypass:

Indicates the number of requests from this client that were serviced by the origin server, because the cache server was bypassed.

Number

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.

Cache hits bandwidth consumed:

Indicates the bandwidth consumed when requests from this client were serviced by the cache server.

KB

The difference between the value of the Bandwidth measure and this measure for a client will reveal the bandwidth that may have been saved by request caching. Where cache is well-sized and used optimally, this difference will be high.

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.

Cache misses bandwidth consumed:

Indicates the bandwidth consumed when the cache server could not serve the requests from this client.

KB

The difference between the value of this measure and the value of the Cache hits bandwidth consumed measure for a client will reveal how much bandwidth was saved by cache hits.

Cache bypass bandwidth consumed:

Indicates the bandwidth consumed when the cache server was bypassed and the requests from this client were served from the origin server.

KB

If the difference between the value of this measure and that of the Cache hits bandwidth consumed measure results in a ‘positive’ integer, it indicates that cache usage has saved considerable bandwidth.

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.