eG Help

To ensure that users are able to access applications on XenApp on-demand, administrators must closely track that user’s application accesses, promptly detect probable access latencies, diagnose its root-cause, and take steps to avert it, well before that user notices and complains. To achieve this, administrators can use the CtxNsIsIcaUserTest test.

This test automatically discovers the users who are currently accessing applications on XenApp, and for each user, reports the latencies that user experienced when interacting with virtual desktops. This way, the test quickly and accurately points administrators to those users who are experiencing slowdowns, and also leads them to what is causing the slowness – the network? the NetScaler appliance? or the server hosting the desktops?

Measurement	Description	Measurement Unit	Interpretation
Application_launch_count	Indicates the number of applications currently launched by this user.	Number	Use the detailed diagnosis of this measure to know which applications were launched currently by the user. Compare the value of this measure across users to know which user has launched the maximum number of applications.
Bandwidth	Indicates the rate at which data is transferred over the ICA sessions of this user.	Kbps	Ideally, the value of this measure should be low. A high value indicates excessive bandwidth usage by the user. Compare the value of this measure across users to know which user is consuming bandwidth excessively.
RTT	Indicates the screen lag experienced by this user while interacting with an application on XenApp.	msecs	A high value for this measure is indicative of the poor quality of that user's experience with applications. To know the reason for this below-par UX, compare the value of the WAN_latency, DC_latency, Client_jitter, and Server_jitter measures of that user.
Client_SRTT	Indicates the RTT (roud-trip time or screen lag time) of this user smoothed over the client side connection.	msecs	TCP implementations attempt to predict future round-trip times by sampling the behavior of packets sent over a connection and averaging those samples into a “smoothed” round-trip time estimate, SRTT. When a packet is sent over a TCP connection, the sender times how long it takes for it to be acknowledged, producing a sequence, S, of round-trip time samples: s1, s2, s3.... With each new sample, si, the new SRTT is computed from the formula: SRTTi+1 = (α ×SRTTi) + (1 - α )×si Here, SRTTi is the current estimate of the round-trip time, SRTTi+1 is the new computed value, and α is a constant between 0 and 1 that controls how rapidly the SRTT adapts to change. The retransmission time-out (RTOi), the amount of time the sender will wait for a given packet to be acknowledged, is computed from SRTTi. The formula is: RTOi = β ×SRTTi Here, β is a constant, greater than 1, chosen such that there is an acceptably small probability that the round-trip time for the packet will exceed RTOi.
Server_SRTT	Indicates the RTT (roud-trip time or screen lag time) of this user, smoothed over the server side connection.	msecs
WAN_latency	Indicates the average latency experienced by this user due to problems with the client side network.	msecs	A high value for this measure indicates that the client side network is slow. If the value of the RTT measure is abnormally high for a user, you can compare the value of this measure with that of the DC_latency, Client_jitter, and Server_jitter measures of that user to know what is causing the slowness – is it the client side network? or the server side network?
DC_latency	Indicates the average latency experienced by this user due to problems with the server side network.	msecs	A high value for this measure indicates that the server side network is slow. If the value of the RTT measure is abnormally high for a user, you can compare the value of this measure with that of the WAN_latency, Client_jitter, Server_jitter, and Host_delay measures of that user to know what is causing the slowness – is it the client side network? the server side network? the NetScaler appliance? or the server hosting the desktops?
Client_jitter	Indicates the client side jitter.	msecs	Jitter is defined as a variation in the delay of received packets. At the sending side, packets are sent in a continuous stream with the packets spaced evenly apart. Due to network congestion, improper queuing, or configuration errors, this steady stream can become lumpy, or the delay between each packet can vary instead of remaining constant. A high value for these measures therefore is indicative of a long time gap between ICA packets. To know where the delay is longer –whether on the client side or on the server side - compare the value of the Client_jitter measure with that of the Server_jitter measure. Also, if the value of the RTT measure is abnormally high for a user, then you can compare the values of these measures with that of the WAN_latency and DC_latency measures to know what is causing the problem – the client side network? or the server side network?
Server_jitter	Indicates the server side jitter.	msecs
Active_apps	ndicates the number of applications on which this user is currently active.	Number
Active_desktops	Indicates the number of desktops on which this user is currently active.	Number
Active_sessions	Indicates the number of sessions within which this user is currently active.	Number	Use the detailed diagnosis of this measure to know the details of the sessions that were initiated by the user.
Total_bytes	Indicates the amount of data (in MB) transferred to / received from this user during the last measurement period.	MB	A consistent increase in the value of this measure over time is indicative of excessive bandwidth usage by a user.