This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
L7 Latency Thresholding
The L7 latency thresholding feature in HDX Insight actively detects end-to-end network latency issues at the application level and takes proactive actions. The L7 latency thresholding feature performs live latency monitoring to detect the spikes and sends out notifications to HDX Insight if the latency exceeds the minimum observed latency.
Previously, average client side and server side L7 latency values were sent every 60 sec to HDX Insight. Any spikes seen within this interval were averaged out and hence remained undetected. Also, there was no live latency monitoring to detect these spikes.
Network latencies are captured and displayed at the L4 level as well. These latencies are calculated from the TCP layer and do not require parsing of the ICA traffic. Therefore, they are relatively easy to obtain and are less CPU intensive. However, the major drawback of L4 latency is understanding end-to-end latency. If there are TCP proxies in the path, the L4 latency captures only the latency from the NetScaler to the TCP proxy. This might result in incomplete information and hence result in difficulties in debugging the issue.
L7 latency is calculated by parsing ICA traffic. L7 latency calculation is done at the ICA layer, and therefore intermediate proxies do not result in incomplete latency values. Thus, provides end-to-end latency detection.
The following figures display a deployment type with and without TCP proxies.
ICA RTT represents the total round trip time from the Citrix Workspace app to Virtual Delivery Agent (VDA). L7 latency provides granular details regarding latencies on the client side and the server side. L7 client latency is the latency between Citrix Workspace app to NetScaler Gateway. L7 Server latency is the latency between NetScaler Gateway to VDA.
Note: Server side L7 latency calculation for the server is supported only for the Citrix Virtual Apps and Desktops versions 7.13 and later.
Add an ICA latency profile.
add ica latencyprofile <name> [-l7LatencyMonitoring ( ENABLED | DISABLED )] [-l7LatencyThresholdFactor <positive_integer>] [-l7LatencyWaitTime <positive_integer>] [-l7LatencyNotifyInterval <positive_integer>] [-l7LatencyMaxNotifyCount <positive_integer>] <!--NeedCopy-->
Add an ICA action.
add ica action <name> [-latencyprofileName <string>] <!--NeedCopy-->
Add an ICA policy.
add ica policy <name> -rule <expression> -action <string> [-comment<string>] [-logAction <string> <!--NeedCopy-->
Bind ICA policy to the VPN server or to the ICA global bind point.
bind ica global -policyName <string> -priority <positive_integer> [-gotoPriorityExpression <expression>] [-type ( ICA_REQ_OVERRIDE | ICA_REQ_DEFAULT )] <!--NeedCopy-->
bind vpn vserver <name> -policy <string> [-priority <positive_integer>] <!--NeedCopy-->
bind cr vserver <name> -policy <string> [-priority <positive _integer>] <!--NeedCopy-->
Latency Monitoring: Parameter to enable or disable L7 threshold monitoring. When this parameter is enabled, notifications are sent to HDX Insight when the set conditions are met.
Default value: DISABLED
LatencyThresholdFactor: Factor by which the active latency must be greater than the minimum observed latency to conclude that the threshold is exceeded and therefore notification must be sent to HDX Insight.
Default value: 4
Minimum value: 2
Maximum value: 65535
LatencyWaitTime: Time in seconds for the appliance to wait after the latency threshold is exceeded to send notification to HDX Insight.
Default value: 20
Minimum value: 1
Maximum value: 65535
LatencyNotifyInterval: Time interval in seconds for the appliance to send subsequent notifications to HDX Insight after the wait time has passed.
Default value: 20
Minimum value: 1
Maximum value: 65535
LatencyMaxNotifyCount: Maximum number of notifications that can be sent to HDX Insight within an interval where the latency is above the threshold.
Default value: 5
Navigate to Configuration > NetScaler Gateway > Policies > ICA.
Select ICA Latency Profiles tab and click Add.
In the Create ICA Latency Profile page, perform the following.
- Select L7 Latency Monitoring to enable L7 Threshold monitoring.
- In L7 Threshold Factor, enter the value by which the active latency must exceed the minimum observed latency to send notification to HDX Insight.
- In L7 Latency Wait Time, enter the time in seconds for the appliance to wait after the threshold is exceeded to send out a notification to HDX Insight.
- In L7 Latency Notification Interval, enter the time in seconds for the appliance to send subsequent notifications to HDX Insight after the wait time has passed.
- In L7 Latency Maximum Notify Count, enter the maximum number of notifications that can be sent to HDX Insight within an interval where the latency is above the threshold. Note: The L7 latency maximum notify count is applicable once the threshold is exceeded and is reset when the active latency falls below the threshold. Periodicity of these notifications is governed by the notification interval.
After configuring the L7 latency threshold parameters, you must configure HDX Insight. For details, see Configure NetScaler Gateway to support HDX Insight.
To view the L7 latency parameters in NetScaler ADM, navigate to Analytics > HDX Insight > Applications or Analytics > HDX Insight > Users.
In the L7 latency measurement module, average client side and server side L7 latency values are sent to HDX Insight every 60 seconds. As a result, spikes seen within this interval are averaged out and hence remain undetected. Also, the L7 latency measurement module does not have the live latency monitoring capability.
The following figure illustrates a sample L7 latency measurement model.
The L7 latency threshold reporting model has the live latency monitoring capability to detect spikes. Notifications are sent to HDX Insight if the latency exceeds the minimum observed latency.
Whenever a threshold factor is exceeded, the latency increase is detected. After the configured threshold wait time expires, a notification is sent to HDX Insight. A subsequent notification is sent to HDX Insight after the wait time has expired and the threshold factor is still exceeded. In case the latency value falls below the threshold factor before the wait time expires, no notification is sent to HDX Insight.
The following figure illustrates a sample L7 latency threshold reporting model.
The following parameters can be configured at run time:
- Threshold monitoring (ON/OFF)
- Threshold factor
- Threshold wait time
- Notification interval
- Maximum notification count
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.