Citrix Blogs

Get a Boost with XenDesktop Bandwidth Optimizations

Amit Ben-Chanoch

XenDesktop Bandwidth: The Complete Set

Part 1 – The Prologue: Methodology and Infrastructure

Part 2 – By The Numbers: Take the time to optimize

Part 3 – Bringing It All Together: Daily User Average and General Recommendations

Part 4 – What About XenApp?

Part 5 – Do It Yourself: Starter Kit

Part 7 – Who needs a part 6 when we’re discussing XenDesktop 7.x (And XenApp 7.5!)

Bonus Customer Analysis!
Bonus HDX 3D Pro!
Part 2: By The Numbers: Take The Time To Optimize

In Part 1, I discussed the methodology and infrastructure used for testing.

In this post, I’ll discuss the policy settings and optimizations that we found to be the most beneficial for WAN deployments and why optimizing is essential for a WAN deployment.

We tested three different configurations:

  1. OOBE: A default “out of the box” configuration
  2. Optimized: A WAN optimized configuration using both Citrix policies and Windows registry edits that does not heavily impact the look and feel of the desktop
  3. Pushing The Limit: A heavily optimized configuration that alters the look and feel of the desktop, but requires the least amount of bandwidth

Before you start thinking, “Wait, why not use CloudBridge?” The answer is that would be a great idea, but we have not completed testing at this time. Would it improve the results? Absolutely. Will it make your life easier? Very likely. Will I be testing it in the future? Hopefully! For now, see the newly released whitepaper about some of the benefits of CloudBridge. More to come on CloudeBridge in part 3 as well.

Before We Begin

As I mentioned in part 1 of this blog series and I will mention additional ones here, there are several disclaimers I must make in regards to the testing. The first (which I mentioned in part 1) is that the tests run with Login VSI do not send mouse clicks and keystrokes from the client to the server and therefore only server side bandwidth is being discussed here.

Secondly, a physical laptop was used as the end point device running sessions at a resolution of 1440×900 (between 720 and 1080) for the configurations tested. The resolution of the session will affect the bandwidth usage. So, if you plan on testing, make sure to test at a reasonable resolution comparable to what users will experience.

Third, the results shown in this blog do not include the logon process. This is because a the logon process requires a significant amount of bandwidth for a short duration and is unrelated to the applications running. A graph of the logon bandwidth is provided at the end of this post.

Configuration 1: Default OOBE

Many customer VDI deployments use images based on physical corporate images; ones that have few or no optimization policies in place.  Because of this, the first configuration is based on this deployment scenario. In a LAN environment, bandwidth will not be an issue even with this sort of deployment, though some optimizations can also yield better scalability in terms of CPU and Memory and should be considered even on the LAN. However, when moving to a WAN environment, bandwidth is an entirely different story.

A default Windows 7 image will include many visual styles and settings that most users do not notice, but require a considerable amount of bandwidth. Many of these settings are “eye candy” and I would argue that they should always be disabled in a virtual environment. To access these settings, open the “Advanced System Settings” dialog, and under “Performance” click on the “Settings” button. What you should be looking at is something similar to the screenshots below (On the right shows a Windows Aero enabled desktop with additional options).

Disabling these visual styles has long been considered a best practice, although in many deployments they are left enabled. During the default configuration, only two of the above settings were disabled; “Animate windows when minimizing and maximizing” and “Show shadows under mouse pointer”. Different deployments may end up with different settings enabled if not properly configured. Aero was not enabled in the default configuration (XenDesktop 5.6’s default policy is to disable Aero Redirection). Note that this is not the case in XenDesktop 7 where there have been significant improvements in bandwidth requirements for Aero redirection and it is enabled by default for Windows client machines.

Configuration 2: Optimized

For the second configuration we implemented some of our own Citrix best practices. The aim was to create a configuration that reduces the bandwidth (quite significantly), but does not noticeably change the desktop experience. Most of these changes are nothing new and include disabling the eye candy mentioned earlier. They were taken from existing documentation such as the optimization guide and policy planning guide. There are only a few additional changes in the configuration other than those from the guides which were mainly application specific.

The changes were implemented both through Citrix policies and Windows registry changes; look for the details of these in a later Do It Yourself blog post. For now, here are some of the main bandwidth reducing policies that we set.

  • Microsoft Registry Changes

    • Caution: Serious problems might occur if you modify the registry incorrectly. For added protection, back up the registry before you modify it. See more about backing up and editing the registry here.

    Note: There are many ways to implement the registry changes above. In this case local profiles were used with a pooled desktop image so we decided to use Group Policy Preferences. Some changes had to be made to the HKLM defaults that are read when a new profile is created. Changes can also be made to the initial desktop image or through HKCU. Results may vary depending on your profile solution and type of desktop so I advise you to test this extensively to make sure all changes have taken effect. I will discuss this further in the Do It Yourself blog post.

    The initial results were very promising. Bandwidth dropped significantly across the board for all applications, in many cases over 50%. The chart below shows the average bandwidth of both the default and optimized configurations in a LAN environment.

    Now these tests were run on the LAN where bandwidth is rarely a concern, so what about a T1 connection? The results were just as impressive with savings of up to 82% (See the results summarized in the chart below). Excel showed the highest savings and was very responsive at even the lowest bandwidth limits.  PowerPoint exhibited the least savings due to animations between slides.

    Savings with similar results were consistently seen at all tested bandwidth levels, although this blog will mostly discuss results found at 1.536Mbps due to the sheer amount of data collected. Responsiveness measured in the manual tests (discussed in blog 1) also improved across the board for all applications at lower bandwidth limits and a table with all of the manual test results can be found here.

    Configuration 3: Pushing The Limit

    The final configuration focuses on further reducing the bandwidth consumption with several more simple optimizations. In this scenario, the look and feel of the desktop was affected as well as server resources due to heavy compression. These configuration changes allowed for additional bandwidth savings as well as responsiveness gains in the manual tests. How was the additional bandwidth savings achieved? For starters, all Citrix compression policies were set to the maximum setting. Also, all visual styles that made the desktop look like the windows 7 desktop were disabled. These settings are summarized below. However, these should be considered carefully as the user experience is inherently different.

  • Microsoft Registry Changes

    • These changes provided bandwidth savings that did not quite match the initial savings seen from the optimized configuration, but in comparison to the optimized image they were definitely significant. The chart below compares the “Maximum Optimized” configuration against the “Optimized” configuration. The difference in terms of kbps saved is significantly lower than between OOBE and Optimized, but for a highly constrained environment small differences can have a big impact to the users. Because these changes really impact user experience, don’t implement them unless you really need to. Test bandwidth usage first to avoid unnecessarily degrading user experience.

    Charts Chart Charts

    I myself am a visual person and so I prefer to digest my content graphically. I believe many others are as well so below I are various graphical presentations of our findings in the application deep dive. Select the thumbnails to view the images.

    Manual Test Results (Through ShareFile)
    Logon Bandwidth
    All Applications OOBE Configuration
    Average Bandwidth Comparison LAN
    Average Bandwidth Comparison (T1)

    Next Time

    In part 3 I will be discussing the averages seen when running the Login VSI Medium workload that includes Internet browsing, 480p video, and idle time to simulate typical user behavior. I will discuss the “daily average” as well as provide general recommendations based on the testing.

    Thanks For Reading,

    Amit Ben-Chanoch
    Worldwide Consulting
    Desktop & Apps Team
    Project Accelerator
    Virtual Desktop Handbook

    Exit mobile version