User Categories

How do we categorize the users in the multiple-user environment? This question has prompted much controversy since the introduction of terminal servers. Three key user categories emerge, shown in the following table. However, they are fully out of context without application and server categories. We will use these categories in this book; yet keep in mind that they do not entirely match the “classic” definitions, which have proven inadequate in the past.

Naturally, these categories do not fully describe all users. In many user groups, not all users work simultaneously or continuously with the computer system. 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. On the other hand, 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 Categories

Many approaches to server dimensioning assume three categories of applications: 32-bit, 16-bit, and DOS applications. But the reality is different. For one thing, almost no DOS applications run on terminal servers anymore. Furthermore, 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. Word, however, is used primarily to enter character strings, which can be easily optimized through the Glyph cache. The categories of applications listed in this table are a far better real- world representation.

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 detail in Chapter 11. However, these tests are not as important for determining the required server resources as the memory requirements.

Server Categories

Servers used in standard terminal server environments have the following subcomponents:

• Computer power Between one and eight processors (CPUs) with clock speeds above one GHz.

• Working memory Main memory expansion between 500 MB and above four GB.

• Hard drive system Powerful hard drives (SCSI or E-IDE) providing between 20 to 100 GB, usually set up in a RAID-1 group (mirroring) for reliability reasons.

• Network At least one network card (NIC) with transfer speeds between 100 megabits per second (Mbps) and 1 gigabit per second (gigabit/s).

Table 5.3 organizes the diverse server configurations into more or less four categories. Only the low-end server has an individual network card, which is used to communicate with clients and back-end servers. All other server categories have two network cards.

Unfortunately, servers do not scale linearly as processors and main memory are added. Tests show that doubling the processors does not double overall capacity. This is valid for all types of processors that function with terminal servers. The rule of thumb is that increasing the number of processors from one to two raises capacity by 50–60 percent. Increasing the number of processors from two to four adds another 40–50 percent.

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 slow main- memory accesses. The larger the cache, the lower the number of memory accesses needed. Doubling the second-level cache increases capacity by about 10 percent.

What about main memory? Settings (for example, /PAE switch in the Boot.ini start configuration file) were already offered in Windows 2000 to enable access to over 4 GB of memory. Yet terminal servers with four or more processors often exhibited saturation behavior after occupying just over 2 GB of physical memory. This was not a problem of direct access to available main memory; the limits were the result of system-internal memory management. Related factors were the available free page table entries in memory and the limited size of the registry database containing system and user configuration data. If any of these factors pushed the terminal server environment to its resource limit, the whole system became unusable, so adding processors and physical memory made little sense. Therefore, rarely were terminal server environments configured for more than 200 simultaneous users. This is why limits on memory management had the greatest impact on the overall performance of systems utilizing large server platforms.

Windows Server 2003 either did away with 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; the registry is now considered a file copy in memory (memory-mapped file). Nonetheless, initial tests on large server platforms still demonstrated limits in managing large numbers of simultaneous user sessions. Improvements to the operating system kernel, however, did double the number of user sessions that can be managed with Terminal Services under Windows Server 2003 compared to Windows 2000 Server.

Figure 5-9: Test on a server platform with eight physical processors (Intel Pentium 4 XEON, 1.6 GHz clock speed, 1 MB second-level cache), 8 GB physical memory, and 132 open user sessions.

In Figure 5-9, each user has one document open in each of three applications (Notepad, Word, and Adobe Acrobat Reader), requiring approximately 60 MB per user session. The sharing of components saves about 2 GB of the total 8 GB required. It is very clear that more than 4 GB of physical memory was in use (total physical memory—available physical memory 4.5 GB). Users were not interacting with the applications at the time the data was captured; the applications are simply occupying memory. System-internal administrative tasks thus accounted for the full processor load! System reaction time to user actions in this scenario dropped noticeably from the time previously measured (dialog and window changes > 10 seconds).

Remember that the values obtained in these tests can differ widely in either direction depending on the application mix and the physical server platform. For accurate results, tests should be performed under actual conditions using the intended target platform. Because large servers tend to use resources poorly, however, the trend has been toward smaller server platforms using a maximum of four processors and 4 GB of main memory. This trend is supported by two newer technologies that might prove 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 VirtualPC (formerly Connectix VirtualPC) or VMware by VMware, Inc.

These two technology trends might result in more farms with numerous smaller individual servers (physical or virtual). These scalability limits hampered most past terminal server projects from deploying large servers with more than four processors. In the future, a typical individual server on a terminal server farm will likely fall into the Standard Server or Enterprise Server category, as described in Table 5.3.

In further support, we also know that doubling the number of server processors usually more than doubles the price of the hardware platform. For large servers, the only potential savings lie in the price of the operating system license and automated installation of the terminal server environment. Even so, these issues will probably be resolved in the near future as well. Microsoft is already developing a licensing model that reflects the number of processors, and a number of manufacturers are offering powerful tools for mass installation.

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.

Dependencies Between the Categories

What are the dependencies between the categories? Only by viewing them in a relatively simple context can we make concrete estimates of resource requirements.

First, consider the impact of the minimum requirements of a certain user category on memory size. The resulting value is derived from the observation that user applications initially use 2–8 MB of main memory after startup.

Add to the values shown in Table 5.4 the 10 MB of memory for each user session on a terminal server (excluding applications). Ten MB is the total needed by Csrss.exe (approx. 2.5 MB), Ctfmon.exe (approx. 2 MB), Rdpclip.exe (approx. 2.3 MB), and Winlogon.exe (approx. 3 MB).

The result is the following formula:

Memory requirement = Number of light users x (10 MB + 10 MB)
+ Number of medium users x (20 MB + 10 MB)
+ Number of heavy users x (30 MB + 10 MB)

To further refine the main memory requirements, we need to classify users not only by category, but also by the applications they use the most. Use the following matrix to help you with this additional estimate. In the calculations in this table, x users of a group need y MB main memory for their applications. A category- dependent percentage is added to the applications’ memory requirement. This percentage covers the use of additional system resources.

In Table 5-5, the application sets of a specific application category are allocated to user categories. The number of users and memory required are totaled per application category. Additional memory is required based on the application and user categories. This added percentage takes into account the average memory needed for additional components (COM components, assembly DLLs, clipboard, and so on). Depending on the environment, it might be necessary to adjust this percentage.

Before this table can be completed we need to know how much memory each application initially needs after start-up and the average memory required once user- specific documents are loaded. The first value represents the basic memory requirement after application start and the second includes the loaded user data.

Finally, the memory requirement is compared to the result in Table 5.6. This is based on the typical processing power needed for certain user categories. We assumed a clock speed of 1.4 GHz and a second-level cache of 256 KB.

Doubling the processors’ clock speed increases computing power by 25 percent; halving it decreases it by 25 percent. Doubling the second-level cache boosts computing power by 10 percent.

The four results of the different calculations are likely to vary. Nevertheless, they represent the range for which resources should be planned. The actual range will fall somewhere between the high and low end.