Let’s Get Real About XenApp and Virtual Desktop Sizing


I’ve seen some talk recently about updating properly sizing workloads and anticipating expected usage on XenApp – and all of it is extremely good – however the question still comes up often enough in IRC, I thought it was worth a mention:  How large should I make my XenApp server?  Today’s gold standard for load testing in virtual desktops or session hosting is surely LoginVSI, but not everyone has the time, funding, or knowledge to execute an effective test, nor can they necessarily quantify their workload to such an exacting standard.  I won’t get into the specifics about how big this or that should be – it has been done to death.  I wanted to point out one, inescapable truth:  Times have changed, and the web has changed.  Guidelines for sizing from 2010 are still filled with excellent information, however they’re just guidelines and need to be tested in your environment.

Ultimately, your environment will depend on a lot of factors, however, if you allow your users access to unknown applications or unknown websites, be prepared to plan to monitor and adjust your sizes accordingly.  Do not simply implement “6 vCPU and 32GB of RAM” and expect to be done with it.  If you allow users to use a browser, specifically, and you’re not tightly controlling access, be prepared for the issues that might arise (either in terms of memory usage or swap I/O *hint hint* PVS with Cache in RAM + Spillover).

Resource usage must be monitored and adjusted on an ongoing basis

Resource usage must be monitored and adjusted on an ongoing basis

With that, I’ll leave you with this:  Imagine this is your web server, and your task worker is working away but happens to pop open a Facebook tab (to chat or just post an update) and leave it open…this is a single tab, left open for 6 minutes, without touching anything.  To say nothing of work-related applications a user might also be using.  1GB/user still sound good?  Maybe, but I’d still monitor.

Leave a comment

Your email address will not be published.