Microsoft Windows Server 2008 R2 Remote Desktop Services

16. Server Sizing

Posted by Benny Tritsch on January 17, 2010

 

 What is harder than building and operating a new Remote Desktop Session Host environment?  It’s planning and sizing a new Remote Desktop Session Host environment.  If you are an IT architect and you want to establish a new environment hosting remote desktops and applications, you may want to know what hardware you need to purchase.  Questions like “What server hardware do I need if I want to give 100 users access to our corporate applications?” or “How many users can I expect to host on a single Remote Desktop server?” are not unusual.  Unfortunately, there are no simple answers to such questions.  Adequate Remote Desktop server sizing and capacity planning is a challenge.

There is a good reason for this; Remote Desktop server sizing is dependent on factors such as available server hardware, application requirements, type of users, network configuration, system availability, and risk tolerance.  This implies that there are many unknown factors to start with, which makes it almost impossible to exactly predict the final result.  On the other side, it is obvious that decision makers, business managers and controllers are not willing to be walking in the dark when estimating the necessary investment into IT infrastructure.

In the past, many industry experts referred to a commonly accepted rule of thumb that suggested 15 or 20 concurrent users per CPU.  Today, due to modern hardware architectures, changing user demands and unpredictable application requirements, this rule of thumb does not apply anymore.  You cannot expect to find a simple solution by estimating user and resource requirements, or by performing some simple calculations and extrapolations leading you to proper results.  But there are some simple strategies helping you to estimate hardware and infrastructure requirements within certain limits.

But no strategy will ever be successful without gathering some important background information first.  To properly size a Remote Desktop server environment, you need to analyze requirements and expectations of users, business managers and system administrators.  The result of such an analysis will give you an initial idea about performance and resource requirements.  Adapting a Remote Desktop server environment in such a way that it meets the required performance level can be done by two different basic strategies: Scaling up or scaling out.  Scaling up refers to using increasingly larger hardware while scaling out is based on using multiple smaller systems that share the workload.

Before you are able to properly size a Remote Desktop server environment, you first need to define the requirements in terms of user capacity, applications, and system availability.  These requirements are your starting point when calculating your server hardware resources.  Adequately adjusting the hardware capacity relies heavily on the number and type of applications on each individual Remote Desktop server.  The users, who can be grouped into different categories, are important as well.  A user's working profile may range from simple data input using just one application to simultaneous use of several, resource-intensive applications.  Even if all users only use one application, resource consumption may be significantly different.  Internet Explorer is a good example for this; while it only consumes a couple of megabytes in one user session it may require several hundred megabytes in another, depending on the loaded components.

When analyzing requirements, the following questions need to be answered: What is the maximum number of users a server can handle?  How many applications can be installed per server?  How to distribute applications and users across multiple servers?  To find the answers requires an in-depth investigation into the available server resources, user categories, and preferred applications.  Ideally, we would have a table with the number of potential users in one column and the matching server configuration right next to it.  However, individual user requirements and application characteristics are so different that it is impossible to create such a table without reducing the complexity of the underlying calculation model significantly.  It’s like you were asking what size of shoe is optimal for people in general, ignoring the fact that there is quite some variance when looking at the different sizes of people’s feet.

That all being said, what could be a working model to find out about server requirements without making it a science?  Here’s a simple and down-to-earth step-by-step guide.

1. Get a server that has a good potential of being the reference hardware for future server sizing activities.
2. Identify the 10 most important applications in your IT environment.  Install the Remote Desktop server and the 10 applications.  Connect the server to the corporate network and to the necessary backend services.
3. Identify a group of test users representing all different user categories in your IT environment.  Provide all your test users with a stop watch.
4. Define a list of at least 10 clear and realistic application criteria for what is acceptable in terms of usability.  These are statements like “It’s acceptable that it takes up to five seconds until the Save As dialog box opens after the Safe As button was clicked”.
5. Over a couple of days, gradually increase the number of test users.  Ask them to report their observations, in particular when test criteria are not met anymore.
6. Monitor important performance counters, such as number of users, CPU performance and memory consumption.  Match this data with the feedback of your test users.
7. Find the “sweet spot” when a maximum number of users can work without reporting bad performance according to the predefined application criteria.
8. Bingo – you just completed a successful server sizing process.
9. Now you may modify the server setup – like installing additional applications or adding memory – and start the sizing process again.

Now you may say that in reality this is impossible to do, and I tend to agree.  It is interesting to note that in most cases the challenge is not on the technical side, it’s rather on the organizational and social side of things.  Think about it…