How exactly do we calculate the DMI metric "Application Performance" for Citrix (DC RUM 12.4.6)? According to the following slide here, DC RUM uses Throughput, RTT and Retransmission for calculating Application Performance. Would it be possible to share the equation / algorithm on how exactly we calculate that for Citrix? One of our customers would be interested to understand that.
What would be the best high-level metric to show the overall Citrix health of Citrix specific Applications / Software Services? Would "Network Performance" be the most suitable metric here? Network Performance is on many Citrix-related out-of-the-box dashboards. Or would "Application Performance" be better to express the overall health of Citrix?
Solved! Go to Solution.
As you will find out on the Citrix dashboard, the Application Performance is calculated differently from other Software Services (as your screenshot shows). The Application Performance metric does give you a good indication if the Citrix is performing well and as such is a good indicator for the high-level metric. If the Citrix performance is poor the Network Performance related metrics (RTT and loss rate) along with examining the server realized bandwidth are good starting points for investigation. Often the case is indeed within the realized bandwidth.
This is taking into the assumption that the problem lies within the ICA and the Citrix servers itself. Important part of the investigation is also to confirm all the supporting functions and back-end applications (that the users are accessing via Citrix) are available and performing. Similarly important is to examine what and how much of the traffic consists of the ICA traffic and if there is enough bandwidth available for the ICA.
A common component to Citrix or direct access users is the
application itself. A direct access user will hit the front-end of the
application. Citrix users access the application via the Citrix server.
So the client to the application is really the Citrix Server, on behalf
of the end-user. So reporting the performance of the Application itself
is key to understanding any user's experience.
Direct access users will have their network performance reported because
the TCP stream between the end-user and the application front-end is
Users accessing applications via Citrix have 2 additional components in their application delivery chain. Network performance to the Citrix Server and the Citrix Servers themselves.
To report the performance for Citrix users we need to understand the performance of network connection to the Citrix servers and the load inside of the Citrix servers (along with the application's performance).
Instrumentation and setup is key for Citrix Users because DCRUM will associate the pages accessed in the application with the end user if it is setup properly and TCAM is being used. TCAM does two things for you. It reports the host metrics (cpu, memory, session count, etc) of the servers and allows DCRUM to link the end user with the application calls. Instead of seeing the Citrix server as a client, the real end user will be the client of the application. (hint: use the "Internal Client IP Address" dimension to see what Citrix server the user came from.)
Simply setup application monitoring as you would for any other application in Business Units. For Citrix, associate the published application with the application in Business Units as well. The data for the application will be automatically added to the Citrix tier in the Network tier section. Do not create a Data Center Tier. Application reports will associate that published application with the application.
If you wish to create a Citrix app - you could create one for the login and initialization process. Monitor the web server, DB server and other components and create an separate application for that. That will show you the Citrix login/initialization performance.
So, to answer your last question - there is not one metric you can use. You really need to take network performance, Citrix server performance and the application performance into account. A slow-down in any one of those would impact the end-user experience.
Where I don't have an exact formula for Application Performance for Citrix services, creating a report like this report may help you understand the relationships. Watch the Server Bandwidth Use, Server Loss Rate and Client ACK RTTs.
Application Performance for Citrix has been changed over the years, sometimes there was no metric there. It's a tough number to definitively use for reporting. The Citrix Dashboard and network performance numbers may be more easily utilized.
The customer would like to have one metric which expresses the overall health of Citrix. In simple terms, they want to know: "How is my Citrix doing for Region XYZ?" Here is a draft of the dashboard (see right section dashboard-01.jpg).
According to the following slide here, "Application Performance" metric (for Citrix) should be impacted (decrease) if:
What we do not understand: All of that looks very good, however, Application Performance for Citrix is quite low. Here is an example: application-performance-01.jpg
Why is the Application performance that low, even though all other auxiliary metrics for Citrix are ok? Maybe it would be good to know the exact equation / algorithm to calculate that metric, and / or to understand if we are missing something.
performance is calculated from single measurement. Every measurement with
operations > 0 is marked as good or bad (we skip rows with operations = 0).
Application performance is [number of good measurements]/[ number of all
comparison is the worst status of the following thresholds:
time is taken if End-to-end RTT is not measured.
The threshold are hard coded and cannot be configured
example of calculation of application performance for some server
performance for the server is 62.5% = 5/8 because there was 5 good measurements
among 8 (5 measurements with 100%). I.e. 5 clients among 8 has good performance
at one sampling interval on some Citrix server and software service.
Does the configured thresholds seen in the attached image impact the threshold for operation time mentioned in this post. You mentioned how the thresholds were hard coded but it looks like command delivery time (Citrix operation time) is configurable within AMD -> Open Configuration -> Global -> Other Protocols Monitoring -> ICA.
It is configuration of slow pages thresholds. So it has impact on slow pages metric not application performance. The thresholds are used by AMD (it compares every operation and sends to CAS number of elements below thresholds). Application performance is calculated on CAS and uses the thresholds from my post.
Has the algorithm for calculating Application Performance (AP) changed in v17.1 HS AMD?
For example, why is AP 75%, 66.7% and 25% as seen in 01.jpg? How are these percentages calculated?
The resolution is 1 period, and these are clients for one specific server IP (Citrix Software Service).
I will focus at 75% to explain what can happen.
75% says that this is aggregated data. We have probably 4 sessions (4 rows from ZDATA) and one of them is application performance affected.
I don't have samples, so it's difficult to confirm, but one probability is that for example Server realized bandwidth for one session is below 128 kbps and this row is marked as application performance affected. If we see aggregated data we have 2 Mbps value.
Application performance is calculated during processing samples, not at report when we see mostly aggregated data.
In fact this is not true anymore in 2019 release. Instead of treating every session equally while calculating aggregated metric, we use amount of traffic (Total bytes metrics) as a weight here. Thus, sticking to Krzysztof's example, aggregated value might be below 70% or aboove 80%, all depends on amount of traffic in every of 4 sessions
The idea of the metric was: percentage of transactions which have good performance (what ever it means). So, we calculate percentage of measurements which are below threshold on several metrics.
So, if you check value of metric for example RTT on whole server you will see low value but it does not mean that you do not have a lot of big RTT measurements.