Notes on Citrix XenDesktop 5.6 performance testing with various latency and bandwidth settings

Before I begin, I’d like to state that this post is meant to be something I can quickly reference to in the future and they are just my observations from working with a colleague to test Citrix XenDesktop 5.6 through a WAN emulator and thin client.  I can’t fully guarantee the accuracy of the tests but what I can say is that we tried our best to build the test pod as close to production environment we’ve been having issues with as possible.

Test Pod Components

XenDesktop Version: 5.6 DDCs x 2

VDA Agent Version: 5.6.300

Desktops: Dedicated desktops with Windows 7, 2 x vCPU, 8GB RAM

Storage: 3Par SAN with 20+ SAS drives

Hypervisor: vSphere 5.1 U1

WAN Emulator: WANem

Riverbed: Virtual Appliance

Firewall:  Stonegate

Monitors: 3 x 24” monitors at 2560x1440

Thin Client: HP t610 with Windows 7 Embedded

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Here are the observations:

• We noticed through our testing is that the highest latency we could set before noticeable typing delay by either a word or half a word was 100ms. 
• 100ms was definitely workable as the slight delay would mostly be noticeable by faster typers
• 150ms would cause one to half a word typing delay for users who type fast while slower ones would notice a few characters.  Either way, while 150ms was still workable, most users would notice typing delays.
• 100ms doesn’t affect the mouse cursor in the regular VDI as much but it does affect the cursor in RDP sessions. 
• Any latency above 150ms causes the mouse movement delays extremely noticeable in RDP sessions where it can be annoying.
• In terms of bandwidth, we noticed we could push the Mbps usage upwards to 8Mbps by simply opening up a browser, navigate to www.flickr.com, then scroll through a page full of images.
• We also noticed that we could push the Mbps usage upwards to 10.2Mbps if we open up Google Earth (the VDA has the optimization pack for DirectX) and navigate around complex terrain such as Paris’ housing neighborhood.
• General usage appears to require around 2 to 5Mbps depending on what is done in the desktop.
• All traffic are spiky in nature so bandwidth usage is not pinned to a high usage rate.
• Riverbed’s non multi-stream optimization can provide reductions but only in a limited capacity.

We haven’t actually done testing with multi-stream where we can prioritize traffic but once we do, I’ll try to remember to update this post.