In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server.

Of course, the design guide is the end result of a lot of testing by the Citrix Solutions Lab. During the tests, we had the Solutions Lab compare many (and I mean many) different configurations where they changed the number of vCPU, RAM size, and RAM allocation (dynamic/static) as well as a few other things. All of these tests were done with Windows Server 2012 with Hyper-V. We ended up with the following:

A few interesting things:

  1. Dynamic vs static RAM in Hyper-V appeared to have little, if any, impact on overall scalability. The only time when the RAM allocation had a negative impact was when not enough RAM was allocated (no surprise there).
  2. The 8vCPU and the 4vCPU configurations resulted in very similar user concurrency levels. Get ready… The battle is about to begin as to whether we should use 8 or 4 vCPU. (Is anyone else besides me having flashbacks to 2009?)

A few years ago, we debated about using 2vCPU or 4vCPU for XenApp 5 virtual machines. A few years later, the debate is resurfacing but this time, the numbers have doubled: 4 or 8. Here is what you should be thinking about… VMs are getting bigger because the hardware is getting faster, RAM is getting cheaper and the hypervisors are getting better (Nick Rintalan provided a pretty good overview on some of the reasoning for this during his discussion on NUMA cores in his XenApp Scalability v2013 Part 2 blog). The whole point is that none of this is new. It has been going on for a long time and will continue to do so.

The hypervisor helped us reduce our physical footprint by allowing us to better utilize our physical hardware. Now, with better technology, we are able to reduce our virtual footprint because the technology is able to support larger VM sizes.

Daniel – Lead Architect