I love talking about scalability almost more than I love making up new “rules” or best practices.
Today I’d like to share a rule that a number of us on our Consulting team have been using for the last couple years that will help anyone easily estimate the user density or single server scalability (SSS) of a physical server that delivers XenDesktop or XenApp-based sessions. In other words, given the specs of a box, I’m going to give you the easiest formula in the world to approximate how many users or VDIs you can “host” on a box.
I call it the “Rule of 5 and 10.” Simply take the number of physical cores in a box, multiply it by 5 or 10 and the result will be your SSS. Done.
Huh? Use 5 if you’re looking for the number of XenDesktop VMs you can host on a box and use 10 if you’re looking for the number of XenApp user sessions you can host on a box. It’s just that simple (and it’s actually amazing how often this rule is accurate). I encourage you to check out any publicly available RA, fire up LoginVSI or look at your real-world deployment to validate these magical multipliers. I was speaking at ServTech and Summit on this topic this past year and showed about 7 or 8 examples of RAs and real-world deployments to back these numbers up… and the average multipliers were literally just above 5 and just under 10. So, I’ve taken the liberty of rounding these numbers off for you and the result is a very simple formula to calculate density or SSS.
Examples always help.
Let’s say you just bought some new blades from Cisco and they’re equipped with dual sockets and 16 cores each (i.e. 2×16). You’re about to embark on your XenDesktop project and you’re wondering how many VDIs each blade can support. Well, 160 VMs, of course! All I did there was multiply the number of physical cores in the box (32) by the magical XenDesktop multiplier (5).
What if you just inherited some older HP gear (with 2×14 chips) to support a new XenApp use case? Well, those boxes can probably support about 280 sessions each. Again, all I did was multiply the number of cores (28) by the magical XenApp multiplier (10). See how easy this is? If I had known calculating user density would be this easy, I never would’ve taken that additional Abstract Linear Algebra course at Tulane to get my Math minor. Oh, well; lesson learned.
Before I get into the variables that can influence these magic multipliers, I want to touch briefly on why I’m seemingly so obsessed with CPU. The reason I’m always talking about over-subscription ratios, NUMA nodes, and now pCPUs, is that our specialized VDI and RDSH-based workloads are CPU-bound 99.9% of the time! That’s right — CPU is the scalability bottleneck or limiting factor these days as opposed to memory, disk/storage or network. So, that’s why I’m intentionally omitting those other key areas…because it really boils down to CPU.
So, then you might ask (and I get these questions a lot, so these are great questions/concerns), what about virtual cores, hyper-threading, clock speeds and if my VM spec has 2 or 4 vCPUs?
Sure, all those things matter to a certain degree, but I’m telling you from experience… nothing matters as much as the number of physical cores in the box! So, try to forget about all those things for a minute when you do your initial sizing using the magic multipliers of 5 and 10. I see so many people trying to factor everything in and it just confuses them more than it helps.
You want to know your EXACT density or SSS? Then let me introduce you to LoginVSI. But if you just want a quick and dirty estimate, use the Rule of 5 and 10 and get on with your day!
Now, I have to put on my Consulting hat and cover myself a bit. Because there are actually dozens of variables that influence SSS and 5 and 10 might not be the right multipliers for you and your exact situation. What if your VDI workload calls for developers vs. medium-ish office workers? Well, in that case, your multiplier might be 2. What if you’re forced to use H.264 vs. Selective H.264 (based on the more CPU efficient Thinwire+)? Your multiplier might be 4 in that case. What if you’re going with Server 2016 vs. 2008 or 2012? In that case, your multiplier might be 9. But what if you tune the heck out of your image, optimize with WEM, use selective H.264, block all those nasty ads and just publish a slimmed down version of IE for light users? Then your multiplier could be 12. The point is that your mileage will absolutely vary depending on a number of factors.
But the Number One variable I’ve found when it comes to determining SSS these days is the number of physical cores in the box. Simply multiply by 5 or 10 and be confident that you’re probably pretty darn close to what your future density will be.
As always, I’d love to hear from you, especially if you have some real-world density numbers from production deployments. Just drop me a comment below and make sure to include what chipset you’re using, which XA/XD version and OS version, which codec, which hypervisor and please give me an idea of how “heavy” the workload is. I’m also always curious to know if you’re optimizing your image with something like WEM or even OSOT and if you’ve included things like AV and monitoring tools in the image.
Hopefully this new rule and updated scalability guidance helps you in your travels. Thanks for reading.
-Nick
Nick Rintalan, Lead Architect, Americas – Citrix Consulting
