Determining the root cause of a performance issue through a Citrix XenApp server can be time consuming, and in some cases impossible. One of the main challenges is isolating a single user’s session end-to-end. After connecting to the Citrix server, a user's unique transactions to the backend application components can become lost in a crowd of other users. While it is relatively easy to see the aggregate performance of the crowd, it is difficult to isolate individual users and investigate their individual transactions. Breakthrough new capabilities were introduced at OPNETWORK 2011 to address these challenges.
Prior to the OPNETWORK announcement, the recommended workflow for tracing a user’s transaction through a Citrix XenApp server involved
manual correlation. The only tool that I’ve seen that allows me to do this in any capacity is OPNET’s AppTransaction Xpert. The key is to look for clues in the Citrix stream that help us “pluck out” the user’s connection to the application server in the data center. For example, in the Citrix stream we may see our user typing an invoice number into a text field. We then search for that invoice number in the backend database queries to find our user’s transaction. While this may sound easy enough, in practice there are a number of factors that could derail our analysis. Some common roadblocks include:
- Encryption
- Missing packets from the SPAN
- No data in common on the backend
Among the most (or perhaps the most) jaw-dropping demonstrations shown at OPNETWORK 2011 involved front-end user sessions that were automatically correlated with the correct backend application transactions. Each user connecting to the Citrix server was uniquely identified by the monitoring solution.
The engineer doing the demonstration selected a Citrix user from the AppResponse Xpert console. Automatically, all of the relevant performance statistics for that user were isolated and presented in a single view. The user’s performance over the ICA session was clearly visible, coupled with the user’s individual transactions and response times into the backend applications. This particular user’s application connected to an Oracle database, so the dashboard presented a clean list of SQL queries that were especially slow. In less than 30 seconds, the product presented the root cause of the performance problem for a single user connecting through Citrix XenApp.
This new workflow represents a dramatic reduction in troubleshooting time. In addition, the data needed for troubleshooting is collected continuously. Most performance problems can be solved without even looking at packets. However, when needed, a clean, end-to-end transaction trace for an individual user can automatically be extracted with a single click. Besides finding the root cause of the problem, it’s nice to also have the evidence needed to justify the fix.
Related Posts:
New Approach for Citrix Application Performance Monitoring and Troubleshooting
Troubleshooting Citrix Performance
Posts
