Performance Testing Citrix

Load Testing and Citrix

I wanted to write a high level overview of why performance testing with Citrix is different from other protocol adaptors and isn’t straightforward.  This is possibly one of the least popular protocols for performance engineers to load test because its simplicity ironically makes it complex. Citrix is designed to deliver secure fat client functionality to thin clients. In order to do this the Citrix protocol can essentially boiled down to:

• Action1: Delivery of a bitmap image from the fat client instance to thin client
• Action2: Relay of the users interaction with the Citrix server i.e. mouse screen coordinates, keystrokes and clicks.

This simplicity means the protocol is scalable and future proofed for any application and technology stacks delivered onto fat clients.  This is a double edged sword as the load testing tool protocol adaptor can only work with those limited actions – meaning they are not exposed to the more in-depth object level recognition performance engineers are commonly accustomed to

Dogs are simple, however communication with them is difficult and involves considerable effort.     

Apologies for yet another bad analogy, but I think it highlights the difficulty facing Perf Eng’s well.  Because the CITRIX protocol is so simple, creating robust load tests becomes problematic.  If a set of events are initiated it is difficult to validate if they have been actioned, successful or failed – as the response is a series of images.  This is in contrast to other protocols such as HTTP – where a response is expected for each request.  Citrix ICA doesn’t have this feedback mechanism, making verification tricky.   Sending physical mouse coordinates to a server is also notoriously fragile – if a window moves slightly or is slow to response (as it the case when load testing) then the series of subsequent actions will fail.

Basic Performance Techniques & Citrix

Performance Engineer’s will always opt for a series of keystrokes in preference to mouse actions as they are infinitely more reliable, particularly if the Citrix server experiences minor delays to screen refresh.  Sync’ing responses and subsequent requests based on a hash of a bitmap image is both inelegant and time consuming.  It is this lack of object feedback that makes Citrix challenging – verification, validation and sync checkpoints become the area where time is most spent.

Loadrunner and Citrix Agents.

Loadrunner does neatly attempt to get around some of these issues by giving the load tester the ability to install agent processes on each of the Citrix instances (Citrix virtual desktop agent).  This gives visibility to sync on items such as text and object information such as focus, visible, checked and enabled.  This will add 2MB per Citrix client, which is worth paying for the extended object and sync visibility.

Tools that have Citrix Support:: Loadrunner, Facilita, Silktest … (Let me know if you know anymore)

One Line Takeaway:

• The Devil is in the lack of object detail: Performance testing of Citrix is paradoxically difficult as the protocol content is simple but object poor.  Because of this, extended planning and preparation time is required when creating load testing scripts when compared to other protocols.

You May Also be interested in:

Loadrunner and Citrix Testing Tips & Tricks Part1

Loadrunner and Citrix Testing Tip & Tricks Part2

Loadrunner and Citrix Testing Tip & Tricks Part3

Tags: citrix

This entry was posted on May 8, 2012 at 8:31 am and is filed under Performance Testing Expert, Random Thoughts and Musing. You can follow any responses to this entry through the RSS 2.0 feed.