HDX Desktop Active Sessions Test

The key to ensuring a more than satisfactory user experience with virtual desktops lies in proactively detecting potential slowdowns when accessing virtual desktops, precisely pinpointing the user session affected by the slowdown, accurately isolating the root-cause of such slowness, and rapidly initiating measures to eliminate the root-cause. The HDX Desktop Active Sessions test facilitates all the above, and thus assures users of uninterrupted desktop access! For every user session that is currently active on desktops, this test monitors the ICA traffic generated by that session, and promptly reports latencies. This way, the test accurately points to the exact session where a user experienced slowness. Also, in the event of abnormally high latencies, the test also leads administrators to where that user’s session is bottlenecked - the network? the NetScaler appliance? Or the server hosting the virtual desktop?

This test is disabled by default. To enable the test, first select the Enable/Disable option from the Tests menu in the Agents tile. Then, pick Citrix NetScaler HDX Insight as the Component type, Performance as the Test type, select this test from the disabled tests list and click < to enable it.

Target of the test : Citrix ADM HDX Insight

Agent deploying the test : A remote agent

Outputs of the test : One set of results for every active session of each user who is currently connected to the VDI infrastructure

Parameter	Description
Test period	How often should the test be executed. It is recommended that you set the test period to5 minutes. This is because, the Nitro API using which the eG agent collects metrics from HDX Insight, is capable of capturing only the performance data related to the last 5 minutes.
Host	The host for which the test is to be configured.
Insight Username, Insight password, and Confirm password	To connect to HDX 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 HDX 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.
SSL	By default, HDX 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.
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
Bandwidth	Indicates the rate at which data is transferred over this ICA session.	Kbps	Ideally, the value of this measure should be low. A high value indicates excessive bandwidth usage by the session. Compare the value of this measure across sessions to know which session is consuming bandwidth excessively. You can also use the detailed diagnosis of this measure to view the complete details of the session in question. The user who launched the session, when the session was launched, the session duration, the client from which the session was initiated, the virtual desktop that was accessed during the session, and the server on which this virtual desktop exists, are revealed.
WAN latency	Indicates the average latency experienced by this user session 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 Round trip time – RTT measure is abnormally high for any session, you can compare the value of this measure with that of the DC latency, Client side device delay, Server side device delay, and Host delay measures of that session 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?
DC latency	Indicates the average latency experienced by this session 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 Round trip time – RTT measure is abnormally high for any session, you can compare the value of this measure with that of the WAN latency, Client side device delay, Server side device delay, and Host delay measures of that session 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 side device delay	Indicates the average latency experienced by this session, which was caused by the NetScaler appliance when ICA traffic flowed from client network to server network.	Millisecs	A high value for these measures indicates a processing bottleneck with the NetScaler appliance. If the value of the Round trip time – RTT measure is abnormally high for any session, you can compare the value of these measures with that of the WAN latency, DC latency, and Host delay measures of that session 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?
Server side device delay	Indicates the average latency experienced by this session, which was caused by the NetScaler appliance when ICA traffic flowed from server network to client network.	Millisecs
Host delay	Indicates the average delay in ICA traffic experienced by this session, which was caused by the server network.	Msecs	A high value for this measure indicates a processing bottleneck with the server hosting the desktops. If the value of the Round trip time – RTT measure is abnormally high for any session, you can compare the value of this measure with that of the WAN latency, DC latency, Client side device delay, Server side device delay, and Host delay measures 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?
Round trip time - RTT	Indicates the screen lag experienced by this session while interacting with desktops.	Msecs	A high value for this measure is indicative of the poor quality of a user’s experience with virtual desktops. To know the reason for this below-par UX, compare the value of the WAN latency, DC latency, Client side device delay, Server side device delay, and Host delay measures of that user session.
Client smoothed round trip time - SRTT	Indicates the RTT (round-trip time or screen lag time) of this session 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 = (α x SRTTi) + (1 − α ) x 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 = β x 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 smoothed round trip time - SRTT	Indicates the RTT (round-trip time or screen lag time) of this session, smoothed over the server side connection.	msecs
Client side 0 window count	Indicates how many times in this session the client advertised a zero TCP window during the last measurement period.	Number	TCP Zero Window is when the Window size in a machine remains at zero for a specified amount of time. TCP Window size is the amount of information that a machine can receive during a TCP session and still be able to process the data. Think of it like a TCP receive buffer. When a machine initiates a TCP connection to a server, it will let the server know how much data it can receive by the Window Size. In many Windows machines, this value is around 64512 bytes. As the TCP session is initiated and the server begins sending data, the client will decrement it's Window Size as this buffer fills. At the same time, the client is processing the data in the buffer, and is emptying it, making room for more data. Through TCP ACK frames, the client informs the server of how much room is in this buffer. If the TCP Window Size goes down to 0, the client will not be able to receive any more data until it processes and opens the buffer up again. The machine (client/server) alerting the Zero Window will not receive any more data from the host. This is why, ideally, the value of these measures should be 0. A non-zero value warrants an immediate investigation to determine the reason for the Zero Window. It could be that the client/server was running too many processes at that moment, and its processor is maxed. Or it could be that there is an error in the TCP receiver, like a Windows registry misconfiguration. Try to determine what the client/server was doing when the TCP Zero Window happened.
Server side 0 window count	Indicates how many times in this session the server advertised a zero TCP window during the last measurement period.	Number
Client retransmit timeout - RTO	Indicates how many times during the last measurement period the retransmit timeout got invoked in this session on the client side connection.	Number	An RTO occurs when the sender is missing too many acknowledgments and decides to take a time out and stop sending altogether. After some amount of time, usually at least one second, the sender cautiously starts sending again, testing the waters with just one packet at first, then two packets, and so on. As a result, an RTO causes, at minimum, a one-second delay on your network. A low value is hence desired for these measures.
Server retransmit timeout - RTO	Indicates how many times during the last measurement period the retransmit timeout got invoked in this session on the server side connection.	Number

You can also use the detailed diagnosis of the Bandwidth measure to view the complete details of the session in question. The user who launched the session, when the session was launched, the session duration, the client from which the session was initiated, the virtual desktop that was accessed during the session, and the server on which this virtual desktop exists, are revealed.

Figure 9 : The detailed diagnosis of the Bandwidth measure of the HDX Desktop Active Sessions test