The IT Melting Pot!

Welcome to the HDX bandwidth testing blog series! In the following posts I’ll be sharing key findings and results from an extensive round of XenDesktop 5.6 / XenApp 6.5 bandwidth testing. Already using XenDesktop 7? Well then stay tuned for the last post in the series where I will be discussing that as well. Before I begin, I want to take this opportunity to thank Andy Baker and Thomas Berger for their tremendous help and guidance in managing this effort.

Part 1: The Prologue

It is not uncommon these days to have great LAN networks with what seems like unlimited bandwidth. I find myself at the office running multiple virtual desktops, uploading my files to ShareFile, all while streaming Spotify to my machine at the same time without even noticing. Even at home you have a nice fast connection just for yourself. Unfortunately many users do not have this luxury due to expensive business grade connections which are often over utilized. Overlooking this fact during a deployment can result in frozen and disconnected sessions and an overall poor user experience. This leaves IT departments frequently asking “how much bandwidth do I need for XenDesktop?”

Of course the answer to this question – in my opinion more so than most questions – is it depends. Why is that? Because it depends on what is on the screen at any given time. The amount of bandwidth consumed will be close to none when the session is idle, but can vary greatly depending on whether a user is typing, browsing a document, running a slideshow, or watching a video. Of course there is always the magic number of 20-30kbps that has been around forever, but that was before the explosion in multimedia content both on the web and now seen more frequently in applications as well . (Although I would note that we did reach and beat that 20-30kbps zone with some of our less multimedia intensive tests).

To help better answer this question our team decided to start running some tests…..a lot of tests. We measured general daily usage, took a deep dive into single application tests, and put some optimizations and best practices to the test. In part one of this blog I will be discussing the infrastructure and methodology for our first round of testing.

Infrastructure

The tests that I will be discussing were run in the environment shown below. A laptop was connected to anApposite WAN Emulator and used as the endpoint for both the manual and Login VSI tests. The emulator was used to control the bandwidth limits for each scenario that I describe later on in this blog post. The other end of the emulator was connected to a switch that was configured to send all packets in and out of the emulator to a mirrored port monitored by a server running Wireshark. This ensured all communication between the client and virtual desktop were captured without interfering with the VSI scripts. The environment infrastructure and desktop pool were also connected to the switch and communicated transparently to the laptop.

The environment was built using the product versions shown below. This is important to note as future tests are planned with XenDesktop 7 which benefits from newer codecs and algorithms for rendering. These tests were also run with the latest version of Login VSI which features more intense workloads than previous versions and a large randomized content library.

• XenServer 6.1
• Microsoft Server 2008 R2
• Windows 7 x86
• XenDesktop 5.6
• VDA 5.6.2
• Receiver 3.4 Enterprise
• Login VSI 4.0

Disclaimers

Before I begin to explain the tests that we ran I need to make a few disclaimers. The first being that quality of service (QoS) was not…

Continue reading here!

//Richard