Memory Requirements For Terminal Servers

Reader mail indicates that one of the knottiest problems for terminal server users isn't fixing problems with existing Windows terminal servers, it's sizing the servers in the first place. Let's take a look at one aspect of server sizing: memory.

Most of you know that memory is the terminal-server resource you use most often. Of course, you need CPU cycles, and you'd better have a good network connection to let all the people who use the terminal server share the link without crowding it. A terminal server should have hard disks with low seek times so the server can quickly fulfill each request and move on to the next one. But to run applications and let users manipulate data, a terminal server needs memory—a lot of it. Windows OSs tend to be memory-hungry in single-user environments. The OS alone eats memory, many popular applications (including Microsoft Office) use a lot of memory, and loading large files uses even more memory. In multiuser environments, memory use is exacerbated because many people use the same computer. Although kernel-mode processes might share memory among all the people who use the terminal server, user-mode processes—-applications that run in user mode—won't. The system allocates a separate memory space to each terminal session. Therefore, I advocate putting a lot of memory in terminal servers.

So far, I haven't presented any surprises. What might surprise you, however, is that the way you make applications available can affect the amount of memory a terminal server needs. For example, many people like to publish individual applications on the desktop of terminal server connections (which is possible with Windows 2000 Server Terminal Services on its own) or even on the client machine's desktop or Programs folders using MetaFrame's application-publishing capabilities. However, when clients connect to published applications, each application creates its own session and runs individual copies of user-mode functions such as winlogon.exe. Also, because each application runs in its own session, the applications that users run can't share memory because the applications run in separate sessions and are isolated from each other. The applications identify sessions by session ID instead of username or SID.

Does this mean that using published applications is inherently a bad idea? Not at all. If you use PCs to run a combination of local and remote applications and want to make the applications as easy to access as possible, published applications are the way to go; using them doesn't require users to know that they're establishing a connection to a terminal server. However, if you plan to publish individual applications instead of entire desktops, you need to take into consideration the additional memory requirements this strategy calls for and plan accordingly.

End of Article