Free Online Publication
Windows Server 2008 R2 Remote Desktop Services
From Beginner to Expert Level
Content
The Book
... Table of Content
... Preface
... About This Book
Part I –
A Beginner's Guide to Remote Desktop Services
1 Overview and History
2 Installation
3 Licensing
4 Configuration
5 Client Software
6 Application Installation
7 System Administration
8 Network Planning
9 Printing
10 User Environment
Part II –
An Expert's Guide to Remote Desktop Services
11 Virtualization
12 RDS Internals
13 Remoting Protocol Details
14 Security
15 Registry Settings
16 Server Sizing
17 Resource Management
18 Testing and Quality Assurance
19 RDS Scripting
20 RDS for Developers
Author's Profile
... About
... Benny's Biography
... Presentations 2009, 2008, 2007, 2006, 2005, 2004 and earlier
Awards

 


Microsoft Windows Server 2008 Terminal Services

8. Server Sizing and Scalability

Posted by Benny Tritsch on August 3, 2008

[Server Sizing] [Requirements] [Scaling Up or Out] [Hardware Selection] [64 Bit]

Back Next

8.1. Finding Out About Requirements

Read in this lesson...

  1. User Requirements
  2. Application Requirements
  3. Server Requirements

 

Before you are able to properly size a terminal 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 the terminal 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.

When analyzing requirements, the following questions need to be answered: What is the maximum number of users that a server can handle? How many applications can be installed per server? How can applications and users best be distributed over several servers? To find the answers, unfortunately, 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.

Every calculation model for server dimensions in multi-user environments is based on ideal assumptions. Previous experience with terminal server projects has taught us that there is no universally applicable formula to calculate the resources needed. For this reason, the calculation models produce rough estimates only. It will never be possible to accurately predict to the megahertz or the megabyte the necessary CPU clock speed and memory requirement – except for ideal, rather artificial reference environments.

Despite these limitations, the following sections describe criteria that may help you when planning the required capacity of your terminal server environment.

User Requirements

How do we categorize the users in the multiple-user environment? This question has prompted much controversy since the introduction of terminal servers. However, there is a commonly accepted distinction between three user types:

  • Users with low requirements, referred to as Light Users, Data Entry Workers or Task Worker: A User of this type starts one to three applications and prefers to use only one of them. Only for the preferred application he uses functions that go beyond the basic feature set. He enters data with an average speed of two characters or mouse pointer movements per second, thus producing a constant load. Such a user has regular working hours and creates a continuous system load.
  • Users with medium requirements, referred to as Medium Users or Knowledge Workers: A user of this type starts two to six applications and uses them alternately. For two or more applications he uses functions that go beyond basic features. He frequently exchanges data between the individual applications, thus increasing the average memory requirements by approximately 10 percent. He uses the applications with an average speed of three characters or mouse pointer movements per second in irregular patterns. Such a user produces temporary peak loads.
  • Users with high requirements, referred to as Heavy Users or High-Performance Workers: A user of this type starts more than five applications and sometimes uses them simultaneously (for example, opening several large documents). He uses expert functions in many applications. He copies multimedia data from one application to the other, thus increasing the average memory requirements by approximately 25 percent. He uses the applications with an average speed of three characters or mouse pointer movements per second at all times, also beyond normal office hours. Such as user produces irregular peak loads.

Naturally, these categories do not fully describe all users. In many user groups, not all users work simultaneously or continuously with the computer system. It may even be necessary to take users with a system administrator role into consideration when looking at resource consumption. Overall, this means that many more users can work with the system than planned. The distinguishing feature is the typical length of time the application is in use, which differentiates the part-time user from the full-time user. On average, a significantly higher number of part-time users can work with the system than pure full-time users. This is why the number of concurrent users at given times is by far more important to know than the number of named users that may eventually log in.

Unfortunately, the behavior of part-time users is a lot less predictable than that of full-time users. All the part-time users could want to work with a certain application at the same time, at month's end, for instance. In this case, they behave like full-time users. The terminal server environment should not reach its point of saturation precisely at that time, of course.

Application Requirements

Typical 32-bit applications behave very differently from one another. An average user working with PowerPoint puts substantially more load on a terminal server than the average Word user, mainly because PowerPoint produces much more graphical output, which the RDP protocol caching mechanism cannot support so easily. Word, however, is used primarily to enter character strings, which can be optimized through the Glyph cache. The categories of applications listed in the following are a far better real-world representation.

  • Applications with low requirements: Applications with relatively low processor, memory, and graphics-output requirements. They use no other components or processes, only text. Typical applications in this category are WinZip (moderate use) or text-based terminal emulation.
  • Application with medium requirements: Applications with normal processor, memory, and graphics-output requirements. They use additional components for specific tasks (for instance, COM components or assemblies) and sometimes access back-end network resources. Typical applications in this category are Microsoft Word (excluding macros), Microsoft Excel (excluding macros), Outlook, Internet Explorer (excluding ActiveX), Adobe Acrobat Reader, or simple database clients.
  • Application with high requirements: Applications with high processor, memory, and graphics-output requirements. They use multiple additional components and access back-end network resources. Typical applications in this category include PowerPoint, graphics programs, development environments, modern ERP clients (for example, SAPGUI), or sophisticated database clients.

A more precise differentiation requires calculating a base value for resources used by each application at and just after startup. This base value includes the time span and processor load for the first instance of the application and for each additional instance – before any user interaction whatsoever. This initial estimate says a lot about what will happen if numerous users try to work with an application at the same time, such as at the beginning of the workday. At the very least, memory is later occupied even if a user is no longer working with the application.

The second key parameter is the additional processor and memory resources used when users are working with the particular application. This value depends on the user data that the application loads. For Word or PowerPoint, exceptional circumstances could generate additional data volume per user as high as 100 MB. The processor load also increases, but the higher load quickly dissipates in most applications.

To obtain a realistic estimate of the memory needed in a terminal server environment, we need to examine the application set, that is, all the applications combined. This will tell us the required maximum memory if every user launched every available application. The first number indicates the memory required for the applications without loaded user data only. The second calculation includes the loaded user data. Although both values are more or less theoretical, they do reveal both ends of the spectrum. It can never get any worse!

If you want similar values for processor and network load, you need to invest in extensive load testing, which is discussed in a separate chapter of this book.

Server Requirements

Let’s imagine you successfully analyzed both user and application requirements when planning a new terminal server environment. The only thing you need to address now is the sizing of the server hardware. At the first glance, this seems not to be a big challenge. Servers used in standard terminal server environments include the following hardware components, which all can be extended within certain limits

  • Computer power: Up to 16 processors (CPUs) with two, four or even more cores, and clock speeds in the multi-gigahertz area.
  • Working memory: Main memory between a minimum of two GB and above 64 GB at the high-end.
  • Hard drive system: Powerful hard drives, with fast disk controllers providing 500 GB to multiple terabytes of disk space, usually set up in a RAID group for performance and reliability reasons.
  • Network: One or more network interface cards (NICs) with transfer rates between 100 megabits per second (Mbps) and multiple gigabits per second (Gbps)

In the following we want to organize diverse server configurations into four base categories. Only the low-end server has one individual network card, which is used to communicate with clients and back-end servers. All other server categories have two or more network cards.

  • Low-end server: One dual-core CPU, 4 GB memory.
  • Standard server: Two dual-core CPUs, 8 to 16 GB memory.
  • Enterprise server: Four quad-core CPUs, 16 to 32 GB memory.
  • Datacenter server: Eight or sixteen quad-core CPUs, 64 GB to 2 TB memory.

Unfortunately, servers do not scale linearly as memory and processors are added. Tests show that doubling the processor cores does not double overall capacity. This is valid for all types of processors that function with terminal servers. The overall performance of the selected processor configuration depends on two other factors; clock speed and second level cache. The second level cache is a memory space located directly on the processor. By caching, it eliminates rather slow main memory accesses. The larger the cache, the lower the number of memory accesses needed.

What about main memory? Even the 32-bit version of Windows Server 2008 enables access to more than four GB of memory. Yet terminal servers with four or more processor cores may show saturation behavior after occupying just over two GB of physical memory. This is not a problem of direct access to available main memory; the limits are the result of system-internal memory management. Related factors are the available free page table entries in kernel memory and the limited size of the registry database containing system and user configuration data. If any of these factors pushes the terminal server environment to its resource limit, the whole system becomes unusable. As a result, adding processors and physical memory make little sense. Therefore, individual terminal servers are rarely configured for more than 200 simultaneous users. This is why limits on 32-bit memory management have the greatest impact on the overall performance of systems utilizing large server platforms.

Windows Server 2008 removed such memory restrictions or increased the range substantially, making it highly unlikely that the free page table entries would restrict access to memory. The potential size of the registry database in main memory was also increased. Nonetheless, initial tests on large 32-bit server platforms still demonstrate limits in managing large numbers of simultaneous user sessions.

Since the 32-bit edition of Windows Server 2008 tends to use resources of very large servers poorly, the trend has been toward smaller server platforms using a maximum of four processors and four to eight GB of main memory. This trend is supported by two technologies that proved to be useful in terminal server environments.

  • Blade servers: Server boards with one to four processors that can be inserted vertically in 19-inch racks housed in special cabinets. Because the boards are so small, a 19-inch rack can accommodate many servers.
  • Server virtualization: Installing virtualization software on a guest system enables you to operate several virtual servers on one physical hardware platform. The virtual servers use predefined guest system resources. Typical examples of this software include Microsoft Hyper-V, Citrix XenServer or VMware ESX Server.

Doubling the number of server processors usually more than doubles the price of the hardware platform. This means for large servers that the only potential savings lie in the price of the operating system license and automated installation of the terminal server environment.
The bottom line is that one-processor systems are generally too small and eight-processor systems are too large for use in terminal server environments. Naturally, there are always exceptions, if special requirements or conditions apply.

 

Back Next

 

Read in this chapter...
8 Server Sizing and Scalability
8.1 Finding Out About Requirements
8.2 Scaling Up or Scaling Out?
8.3 Selecting the Right Hardware
8.4 Is 64-Bit the Solution?