SYN311: Optimizing server scalability and reducing bandwidth requirements for XenDesktop/XenApp

So lets start with the 64 thousand dollar questions…Why optimize?
Do you really need to optimize? If you have more servers than you know what to do with maybe you
don’t need to, but for many of you that is certainly not the case.
So maybe you need to squeeze in a few more desktops, but cannot add any hardware.
Maybe you are delivering desktops or apps to a small branch office and need to minimize the strain on
the WAN.
Well in the next 40 or so minutes we are going to talk about these optimizations from Citrix policies to
Microsoft registry changes to get the most out of your hardware and network.
We will start off with a focus on operating system optimization for server scalability and then take a
closer look at the specific optimizations and settings that can significantly reduce the bandwidth
requirements for delivering to that small office.
Now we will mention this throughout the presentation, but I’ll start off here and tell you that when it
comes to optimizations, there is really no one size fits all approach, although I will point out a few that
everyone should look into.

So when it comes to optimizing the operating system, you can break down optimizations into several
categories.
Deployment optimizations are those that should be done during the creation of the desktop or golden
image. These include reducing the storage footprint by removing the bitlocker drive during installation or
setting a static pagefile.
Runtime optimizations on the hand can be implemented in a combination of ways, by inserting them into
the master image, through group policy, scripts and many of which are made in the registry. These
include services, scheduled tasks, visual effects, and other changes.
Lastly, applications themselves can be optimized as well. Some vendors provide optimizations or best
practices for virtualization and since most interactions a user has is with applications, seamless apps
through XenApp for example, these should not be overlooked.
Using these categories, we recently created a guide with around 125 optimizations focused on Windows
8 and 8.1 and Roger will explain the benefit we saw when we put these optimizations to the test.

We decided to put these optimization to the test to validate their effectiveness and show you what sort
of benefit you may see.
To do this, we decided to use the industry standard for load testing, LoginVSI. We went with their widely
used Medium workload which includes interaction with the Office suite, Internet explorer including
video, Adobe Reader, Freemind, and picture a viewer. For those who are not familiar with LoginVSI, they
have a booth in the expo and I encourage you to speak with them.
Alongside the simulated workloads, we captured various metrics both at the hypervisor and virtual
machine level as basis for comparison and the results were even better than I had hoped.

Before we get into the results, for the sake of transparency, here are the specifications for the testing.
The desktops were hosted on an HP Proliant blade server with 16 cores and 192 GB of memory. They
were delivered via provisioning services 7.1 with the write cache drives residing on an EMC storage array.
The desktops themselves ran Windows 8.1 with the XenDesktop 7.1 VDA and were given 2 vCPUs and
2GB of memory on Hyper‐V 2012 R2.
Two configurations were tested at 80 desktops each. 80 was chosen as we needed the same number
each time and at 2GB of static memory it left 32GB for the hypervisor and a buffer.
The first configuration was a “default” in which XenDesktop was installed and the automatic
optimizations made by the VDA and the PVS Optimizer tool were allowed to run. We decided to run
these as to not positively skew our results and since many customers run these automatic optimizations.
In the second configuration, all 125 optimizations in the previously mentioned guide were applied. Now
although we could not directly measure each optimization in this way, it allowed us to show the benefit
that these could have on an environment.
With that said, lets take a look at the results.

Lets take a quick look at some of the results.
These results are during steady‐state meaning we let all the machines logon and kept them running with
LoginVSI.
First lets look at the hypervisor level. Most impressive was the change in CPU usage. We went from an
average of 55% run time down to 42% which amounts to a 24% gain. Now since many times these days
the CPU is the limiting factor on a server, kicking that down a notch can be the difference in getting those
extra desktops deployed.
We also saw noticeable differences in context switches, disk, and memory pages, but as you can see the
network traffic was reduced considerably partly due to a leaner image deployed through provisioning
services and partly due to removing the visual effects.
You can also see on the virtual machine level that we gained around 200Mbytes of free memory, but lets
take a look at a couple of these visually.

As you can see here, we have a graph comparing the CPU usage on Hyper‐V of the Default and Optimized
runs. Each of these is an average of 5 runs which we ran for consistency and during the runs you can see
the CPU is consistently higher without the optimizations.
Now as for the numbers I had just previously mentioned, (Click to show steady state) the steady
state section can be seen here once all 80 machines are running simultaneously.

What we are looking at here is a comparison of 2 machines memory during test runs.
Before starting the test run, you can see they each have memory available, however the optimized
desktop has around 200MBytes of additional memory due to a leaner image.
This 200Mbytes lasts throughout the entire test run and at 80 desktops this amounts to around 16GB of
freed up memory for more desktops, more applications, or less page file usage.

When it comes to implementing these optimizations, there a re quite a few ways to do so.
You can insert many into the base image, the deployment optimizations I mentioned previously definitely
should.
Some can be controlled through group policies which is easily tracked and controlled.
Logon scripts may work for some, although I typically try to avoid them.
Some require registry changes which can be implemented through any of the above. Group Policy
Preferences are a simple way of incorporating registry changes. Note that registry changes may be done
on a machine context or user context and in the case of visual effects, these can be a little tricky.
***Insert Graphical Timeline/Layout

• Some of the changes to visual effects need to be done in the registry in the user context. This can
become tricky with non‐persistent desktops as some require a reboot to take effect, but a reboot will
also revert back to a clean desktop. These may be a bit of a hassle but are worth the effort as these can
significantly reduce the bandwidth consumption and improve the user experience in WAN connections.
• To help implement these optimizations lets take a look at three solutions for non‐persistent desktops.
• Luckily, if using roaming profiles, which very many of you probably are, the changes will get written to
the profile on reboot and take effect on second logon to the desktop.
• For those who use clean profiles each logon, you can implement some of these changes into the
machine registry which will take effect for new profiles. Of course local profiles on non‐persistent
desktops will take additional CPU and allow for less personalization for your users.
• For those with mandatory profiles, you can base the profile on a preconfigured template with the
optimizations using UPM or other profile solution.

• Now you might be asking where is Server 2012 R2 in all of this.
Well using the same methodology, we tested 7 virtual servers with 120 users each time with similar
optimizations and saw very little improvement.
So far we believe this is due to several factors. There were less optimizations that applied to the server
operating system, many of the settings were machine based and in this case there were far less
machines, and that Microsoft delivers a lean Server OS and XenDesktop makes several changes by
default leaving less room to optimize.

• Speaking of the visual effects Roger had just mentioned, lets a taker a deeper look at some of the
Bandwidth Optimizations and how to quickly reduce the bandwidth required.

“I can’t upgrade my connections, but I need to deliver virtual desktops and apps to a remote site.”
I have heard statements like this from customers directly, through partners working with customers, and
through our own sales engineers and consultants.
Although bandwidth is far more abundant than it was even a few years ago, WAN connections continue
to be expensive and applications continue to become more graphically intense and more animated
requiring more bandwidth.
Over the last year I have had the opportunity to extensively test different aspects of XenApp and
XenDesktop and show how simple changes can significantly reduce the bandwidth requirements.
Let’s take a look at what you can do by exploring different ways to reduce the bandwidth requirements.

I want to start off with describing some of the testing I was able to perform before I go over the results
and the best part, best practices and recommendations for XenDesktop and XenApp 7.x
We covered XenDesktop 5.6 XenApp 6.5 and XenDestkop 7.x and performed a multitude of tests with
different applications and configurations.
We used LoginVSI 4.0 to simulate not only the Medium workload, but we also broke out each of the
most common applications within the workload individually to look at specifically how much bandwidth
each one used.
Each test was performed at multiple network limits, and in a few minutes I will show you why that was.
In addition to the simulated test, we performed manual testing at each network limit to determine the
user experience.
With all the configurations, products, networks, and workloads and running each one multiple times to
ensure repeatability, we ended up running roughly 1500 tests.
Lets start with XenDesktop 5.6 and XenApp 6.5 which use adaptive display now known as Legacy mode
and go through a few examples to stress the considerations when wanting to reduce the bandwidth.

The first round of testing consisted of three configurations which I want to quickly go over before we get
into the considerations of for reducing the bandwidth.
The first was a default configuration with no policy changes or registry changes other than those required
for LoginVSI. This was run on Windows 7 and Server 2008R2 and was used a s a baseline out of the box
configurations for comparison.
The second configuration was an optimized configuration for the WAN to reduce the bandwidth, without
limiting the desktop experience too significantly. On the Citrix side, we reduced the frames per second
from 24 down to 15, added additional compression and disabled the wallpaper and some of the visual
effects.
We then disabled the rest of the visual effects through registry settings as Roger had described earlier
excluding “use visual styles” which would disable the Windows 7 experience as we would then use the
classic gray startmenu and theme.
We also optimized Adobe reader as per a knowledge base article from Adobe and disabled the splash
screens from Microsoft office although I have found that users like the loading screen to see that the
application is loading correctly.

The last configuration was we called “max optimized”. In this case we wanted to further recduce the
bandwidth and this time even if it affected the desktop feel. We reduced the FPS further down to 10,
although note that at 10 FPS server rendered video will be noticeably affected. We also reduced the
visual and audio qualities and disabled device redirection like USB, drive mapping, and Twain.
We disabled that last visual effect and used the classic theme, and also disabled cursor blink although
that could have really gone in either configuration.

First off, lets note take a look at the LoginVSI medium workload.
What we are looking at here is a comparison for all three configuration between the bandwidth
consumed on the LAN and that consumed on the WAN which for our purposes was a simulated T1
connection.
Now since HDX is adaptive to the endpoint and network, it will consume more bandwidth on a practically
limitless LAN than it would on a WAN. This is why testing was done at 6 different network limits, but for
the purposes of today’s presentation I will focus the rest of the results on those tested on the simulated
T1. If you are performing your own testing, make sure to test on a similar network to your WAN.
As you can see here for the medium workload, which in this case was run using server rendered video,
the bandwidth was reduced quite significantly.
Next let’s take a look at how they affected some of the applications specifically.

Now what we have here is 5 of the most widely used applications compared for each of the three
configurations.
Each of these was run as custom workloads in LoginVSI by stripping out the same Medium workload I
just showed in the previous chart of all interactions except those of the application being tested.
Now as you can see, the drops in bandwidth are significant across the board, but some apps benefited
more than others.
Adobe Reader, for example had a very considerable drop with the optimized configuration due to the
changes that we found in Adobe’s knowledge base.
I would encourage you to check with your vendors if they have any best practices for delivering their
applications XenDesktop or XenApp.
This can save you not only bandwidth, but also considerable memory or CPU as well.
Let’s talk a little about video now.

Now delivering video is always a hot topic, and what you can see here is the difference a few minutes of
video can make to bandwidth required for the workload.
This is a comparison of the LoginVSI medium workload with server rendered video, and the same
workload without any video. Now server rendered video is pretty much the worst case which is why I’ve
shown it here.
You can reduce the bandwidth video requires significantly through the use of flash redirection or
windows media redirection, but sometimes those just are not an option.
If you simply must deliver server rendered video, lets take a look at the H.264 SuperCodec in
XenDesktop/XenApp 7.x

Here is a comparison of XenDesktop 5.6 or XenApp 6.5 codecs known as Legacy mode and the H.264
codec.
What we are looking at here the frames per second delivered during one of the LoginVSI videos for both
the SuperCodec and the adaptive display codec now known as Legacy mode.
We were able to deliver almost twice as many frames per second while using 15% less bandwidth!
If you want to reduce your bandwidth requirements while delivering a better video experience, take a
look at upgrading your environment if you have not done so already and make sure your receiver version
can support it.
Now speaking of the H.264 codec, let’s talk about the best practices for XenDesktop and XenApp 7.x

With XenDesktop/XenApp 7.x there are three encoding methods to choose from which play a significant
role in determining the bandwidth and user experience so let’s go over when to use each one.
Desktop Composition Redirection, also known as DCR, is the next iteration of Aero Redirection for those
who are familiar with it and is the default for XenDesktop. While it can save on CPU while delivering all
the Aero features and delivers a great user experience, it is also currently the most bandwidth intensive
option and I do not recommend it for the WAN.
To disable it, simply disable the policy in Citrix Policy.
The H.264 codec was born out of a lot of work in the development of HDX 3D pro and is default for
XenApp 7.x and for end points that cannot support DCR. It does require some computing resources for
the compression, but it can deliver a better user experience to any device, especially if server rendered
video is a requirements as you have just seen or any graphically intense application for that matter. I
recommend the H.264 codec for the WAN and for those devices that do not support DCR.
It is enabled by default whenever DCR is disabled and it’s visual quality can be controlled through Citrix
Policy.

The last method which known as legacy mode due to the policy of the same name revert to the
XenDesktop 5.6 and XenApp 6.5 Adaptive display settings which can be configured using the older
compression settings. I would recommend using this if server scalability is a real limiting factor and is
more important than the user experience. I would not recommend this if you need to deliver server
rendered video.
I’d like to note that Legacy mode is not supported in Windows 8 and 8.1 and that it must be explicitly
enabled through Citrix Policy.
Now no matter which encoding method you use, the main citrix policies that affect bandwidth are as
follows:
Frames Per Second will reduce both the bandwidth and CPU as less frames are sent down to the end
point. It is 30 by default and I would not recommend reducing this below 15 if video and animated
applications are being delivered.
The visual quality can be controlled for each of three encoding methods and are medium by default.
The audio quality can also be reduced, but note that if you are going to use VoIP, I would not recommend
reducing this to low.
Multemida redirection continues to improve and I would recommend using flash and windows media
redirection for video and HDXRealtime for video conferencing and VoIP especially with the Lync plug‐in.
Lastly, reduce the visual effects that can be controlled through Citrix policy easily like menu animations
and reduce any others through registry changes.

To help in choosing the right encoding method and its compatibility, I created a cheat sheet which is also
available online and I will share with you the links in just a few moments, but lets take a look at putting
these optimizations to the test with production users.
31

On top of the testing I had done with XenDesktop 7 using LoginVSI, I had the opportunity to test out
some of the optimizations at a customer recently who was kind enough to let me share some of the
results with you today.
During a production pilot to a WAN, in this case the WAN was a 20Mbits connection with around 50ms of
latency, we used policies and optimizations for bandwidth reduction to deploy Hosted Shared Desktops
running on Server 2012.
Around 20 pilot users connected to the environment with Wyse thin clients, half of which were with dual
monitor workstations, which requires additional bandwidth.
We then monitored and analyzed the bandwidth over a 2 week period and found the average bandwidth
usage to be around 100kbps.
This includes printing over HDX and a variety of office and specialty applications and was even better
than we had hoped!
Now what could you do as the next steps to reduce bandwidth and increase scalability? Roger, why don’t
you take us home with what everyone should do next.

So what can you do next to optimize you environment.
Well first of all, decide if optimizing is right for you. If you have a perfect environment and servers to
spare,
For scalability, consider optimizing your desktop image. If using the newest Server OS, consider some
basic deployment optimizations to reduce storage.
If your network is strained, get rid of the visual effects. I personally don’t care for them and on a WAN
they can even make the desktop seem less responsive due to the extra strain they add.
Of course if you are on the older versions, consider this a good time to upgrade, especially if using server
rendered video or if you’d like to use the newer operating systems.
If using or planning to use XenDesktop/XenApp 7.x, determine which encoding method is best for your
user groups by their location. Are they on a WAN? Are they likely to need access through mobile devices?

Check your Receiver! I have seen this quite a few times now where the receiver did not support H.264
decoding so – Windows ‐ 3.4, Mac ‐ 11.8 , Linux ‐ 13. Now with StoreFront 2.5 you can even use the
HTML5 receiver for web with H.264.
Also check with your vendors on applications to optimize as that will be the main interaction for users.
And lastly before we wrap up, do not forget to test! Some of the optimizations in the guide are fairly
advanced so make sure they do not interfere with any applications and feel free to let us know of any
issues using the feedback link within the document.

For those who would like to start optimizing, you can find the Windows 8 optimization guide by
searching for the CTX article
You can find a multi part blog series covering different aspects of XenDesktop and XenApp bandwidth on
the citrix blogs or through the link here.
You will also find in the blog series a starter kit with registry keys and policies specifically for reducing
bandwidth.
And last, but definitely not least, you can find much of this information and so much more in the Virtual
Desktop Handbook so if you have not heard of it, check it out and its great new look.
Thank you very much for attending, we hope you had a great week at Synergy, I hope you enjoyed our
session today, and have a great time tonight at the show.

SYN311: Optimizing server scalability and reducing bandwidth requirements for XenDesktop/XenApp

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie SYN311: Optimizing server scalability and reducing bandwidth requirements for XenDesktop/XenApp

Ähnlich wie SYN311: Optimizing server scalability and reducing bandwidth requirements for XenDesktop/XenApp (20)

Mehr von Citrix

Mehr von Citrix (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

SYN311: Optimizing server scalability and reducing bandwidth requirements for XenDesktop/XenApp