Project VRC: a deep dive into VDI performance tuning

Written on Sep 27 2010 Filed under: VDI, VMware View, Performance 10,311 views, 9 comments

by Jeroen van de Kamp

Ruben and I are pleased to announce we finally can release the long awaited Phase III whitepaper. As promised: this one does a true VDI deep dive. We think we have interesting new content, and more importantly, many new insights.

More and more organizations are planning a move to VDI. Experience in many VDI projects has proven so far that the performance and sizing issues are still a major hurdle to overcome. Often, VDI results are disappointing because the VDI environment is not properly sized and tuned. In practice, storage remains the number one challenge in today’s VDI deployments.

In this whitepaper Windows XP and Windows 7 are extensively compared. Specifically, the I/O behavior of Windows XP and Windows 7 is investigated in detail. By evaluating the different phases of a desktop workload, completely new insights are given.

Windows 7 has a much bigger disk footprint and consumes more memory than Windows XP. It would be reasonable to expect that Windows 7 requires more resources than Windows XP. Although this is certainly true, several tests in this whitepaper prove that Microsoft managed to optimize Windows 7 disk I/O behavior in specific phases of a desktop workload in comparison to Windows XP.

Many best practices are available to optimize Windows 7. Project VRC performed tests with the default optimizations configured by VSI (referred in this document as ‘VSI optimizations’) and additional optimization best practices that are specific to Windows 7 (referred as ‘VRC optimizations’). Both from an I/O and VSImax (maximum capacity) perspective, these ‘VRC optimizations’ proved to have a significant positive impact.

Project VRC also investigated the performance impact of topics like ‘Page file configuration’,  ‘Address Space Layout Randomization’,  ‘VM logging’, ‘ESXTOP’, ‘1 vs 2 vCPU’s’, ‘ESX 4.0u2 vs ESX 4.1’, and ‘Overcommitting Memory’. There are many lessons to be learned here, but the impact of disabling ASLR was striking. It is difficult to blindly recommend disabling such an important security feature, but the impact is large enough to consider it.

All tests were performed with either vSphere 4.0 U2 or 4.1 as the hypervisor and all VDI tests were performed using View 4.0. Apart from specific recommendations for vSphere, all Windows related conclusions are valid for any kind of hypervisor or VDI solution.

The ‘Project VRC phase II version 2.0’ whitepaper evaluated the impact of configuring a higher HaltingIdleMsecPenalty value on vSphere with Terminal Server workloads. This setting improved hyper-threading performance considerably for vSphere under high loads. Although no specific hints were given by VMware or the community, Project VRC investigated  if a higher HaltingIdleMsecPenalty value would benefit VDI workloads. Surprisingly, a significant performance increase (more than 20%!!!) was witnessed for both Windows 7 and Windows XP workloads. The difference was so high that Project VRC internally started to call this the ‘Red Bull setting’. 

Project VRC highly recommends to evaluate the data in this document carefully. Project VRC realizes there are always valid reasons not to use a specific settings mentioned in this paper. Real world VDI environments will always be different from the test-setup in the Project VRC labs. More importantly, Project VRC must emphasize that it is crucial to test and validate these optimizations in your own VDI deployment.

As usual, you may download the paper from www.virtualrealitycheck.net.

Follow Ruben on twtter: @rspruijt

Follow Jeroen on twitter: @theJeroen

Comments

Daniel Feller wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 8:17 AM

I just started going though the doc and got to the optimization pages.  You've recommended the disabling of Windows Search.  I'm not sure that is a good idea.  If you disable that service, try doing a search in Outlook.  It doesn't work. I don't know about the rest of you, but I tend to search quite a bit within Outlook. If that doesn't work, I wouldn't be happy and I bet many other users won't be happy either.  

We have to be careful when recommending what to disable and what to leave alone. I think we should do some of the optimizations to help lower the IO impact of the Windows 7 desktop, but the more we try to optimize, the greater the chance that we will break something else.  I went on a little rant on my site the other day talking about taking optimizations too far.  My recommendation is to only disable the things we know will have a major negative impact but will not break the system. Defrag would not be good and if we disable, we know it won't break an application. Search would not be good. Although it will impact IO, users need this functionality.

Svenh wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 9:01 AM

Hi Daniel,

I'm still able to search within Outlook if I disable the Windows search service. Which version of Outlook are you talking about?

Daniel Bolton wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 9:19 AM

Same here... Windows search disabled and Outlook 2010 still searches fine - all be it a tad slower.

I think on RDS it wont use it by default anyway.

But I do agree with the other Daniel "We have to be careful when recommending what to disable and what to leave alone"...

User experience/acceptance is very important to.

Daniel Feller wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 9:37 AM

I ran into this with a customer and I've even tested it myself.  If I stop and disable Windows Search, then Outlook 2010 can't search my email. If i only stop, then search will auto restart when you try to search.

Jeroen van de Kamp wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 10:33 AM

Daniel, from a functional perspective, you are absolutely right: search is an important feature of Windows 7 (I cannot live without it).

However, from an I/O perspective, it has a significant impact.

Also, search is stored on a machine level. In pooled VM environments you need to reconfigure the location to the homedrive or profile. But doing this will impact the file server and/or profile size considerably.

I agree with you, but the performance impact is worth considering disabling search. If you have persistent/personal VM’s, and enough I/O capacity: enable it.

Daniel Feller wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 10:55 AM

Windows Search actually is comprised of the search functionality and the indexing functionality.  You can optimize indexing, which will positively improve IO without disabling Search.  If you think about it, the indexing is kind of dumb when using a pooled desktop model where any user can use the desktop.  If we redirect the index to a different location, so what.  A different user will log on and the index won't include their data files as they are on the network.  It only indexes local files and I hope we aren't storing local data on a pooled desktop. So what is a user going to search for that would be indexed? You could redirect the indexing location to the profile and only index certain locations, but now we are greatly increasing complexity and probably increasing the risk of issues.  

Of course if you remove all of the indexing locations, search will be slower, you just have to see how much slower it is and if it fails to meet the user expectations.

My main concern is that i've seen too many people blindly implement these optimizations to then spend hours or days trying to figure out why something doesn't work.    

Jeroen van de Kamp wrote re: Project VRC: a deep dive into VDI performance tuning

on Wed, Sep 29 2010 11:06 AM

"....Project VRC highly recommends to evaluate the data in this document carefully. Project VRC realizes there are always valid reasons not to use a specific settings mentioned in this paper. Real world VDI environments will always be different from the test-setup in the Project VRC labs. More importantly, Project VRC must emphasize that it is crucial to test and validate these optimizations in your own VDI deployment..."

Daniel, good point. As you can see from the quote from the article, we agree. Blindly copying any recommendation is not recommended. (pun intented)

Jeremy Saunders wrote re: Project VRC: a deep dive into VDI performance tuning

on Thu, Sep 30 2010 3:40 AM

It is a fantastic document, and as always you guys are doing a great free service to the community. As alluded to, it is important to understand exactly how any optimization will effect the user experience. That makes sense for those of us that have been around in the SBC game for many years. However, what I've seen is that the new kids on the block that are implementing Desktop Virtualization don't necessarily understand this, and do tend to blindly copy these sorts of recommendations without thinking.

Cheers,

Jeremy.

Kimmo Jernstrom wrote re: Project VRC: a deep dive into VDI performance tuning

on Thu, Sep 30 2010 11:17 AM

Thanks @Jeroen and @Ruben for a great document. Great community service!

I also like the healthy discussion on optimization and tweaking in the comments here..

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.