eG Monitoring
 

Measures reported by CtxNsIsWebCtTest

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 CtxNsIsWebCtTest 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?

The measures made by this test are as follows:

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 IIndicates 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 Requests 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 Requests 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 Requests 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_bw_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_miss_bw_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_miss_bw_consumed measure for a client will reveal how much bandwidth was saved by cache hits.

This measure will not be reported for Citrix NetScaler Insight versions lesser than v11.x.
Cache_bypass_bw_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_miss_bw_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.