by Greg Shields

At the same time you determine the applications you want to host in your Terminal Services environment, your planning process should include an analysis of the number of concurrent users you expect to be able to host on a single server. Lacking formal testing software, this process for the small environment is often as much “guess-and-check” as formal procedure. As this series is designed with the small environment-and their available resources-in mind, let’s analyze how you can determine anticipated user load with one tool you have available today: PerfMon.

PerfMon allows you to measure system counters relating to a specific computer. The use of PerfMon in the Terminal Service environment is critical, due to the propensity for users and applications to over-consume resources and cause other users’ experience to go down. Also, PerfMon is the only tool natively available in Windows that can measure how an application uses resources during its normal processing.

The best way to gain a good understanding for resource use is to measure PerfMon counters in two different places. First, prior to installing a new application to your Terminal Services instance, you will want to measure that application’s metrics under a typical load-that is, the resources it uses when a user “typically” interacts with it. Second, you will want to measure the same sorts of counters on your Terminal Servers while they are in production use to assist you with determining their overall level of load. This will help you with determining when you should bring additional hardware to bear to support the needs of your users.

One problem with PerfMon for many IT Pro’s is in wading through its large list of counters to find just the ones that matter. Back in May of 2007, I penned an article for MCPmag.com (http://mcpmag.com/features/article.asp?editorialsid=735) that discussed a number of counters that are useful for measuring virtualization candidacy. These counters and their descriptions are equally as useful when considering the amount of server resources you’ll need to support your Terminal Services users and which applications to host:

• Disk\% Disk Time. If disk time is high, then that server likely does a lot of reading from and writing to its hard disk subsystem. Since virtualization environments encapsulate whole machines into single files, a high disk time counter can mean an excess of writes to its disk file, potentially becoming a performance bottleneck.
• MemoryPages/sec. When the processor is looking for data that doesn’t reside in physical RAM or when the server needs to move unused data from RAM to disk, this increases the metric for MemoryPages/sec. A high counter here could indicate often-changing processes or workloads that require lots of dynamic data. Since the physical RAM on a virtual machine is also just a file on disk, an overly high counter here could signal a potential performance concern.
• Physical DiskCurrent Disk Queue Length. Related to both of the above counters, if your server is reading and writing to its disk so much that its disk subsystem cannot keep up, you will see a high Current Disk Queue Length counter. As with the previous three counters, the disk-based nature of virtualization lends itself toward the potential for disk bottlenecks. Not virtualizing servers that are disk-bound may be necessary for the total performance of your virtualization environment.
• Processor\% Processor Time. The processor in each virtual server is a component of the physical processors on the host. Most of what virtualization software does is schedule physical resource use based on the needs of each virtual server. So, if you are seeing servers with a high Processor Time, then that server is constantly needing the attention of its processor. That constant need could prevent other virtual servers from getting their fair share unless you establish resource limits on the host-in the end, it slows everyone down.
• SystemProcessor Queue Length. If you’re seeing a high percentage Processor Time metric, you may also see a high Processor Queue Length metric as well. This metric deals with a processor’s ability to “keep up with the load.” To complicate things, it can also mean that the hardware of your physical server is not good enough to support its hosted applications. So, keep an eye on this metric. If you see a high count for this metric, but you know your physical server is too old and slow to support its applications, you may improve performance by moving to virtualization. But, if you see a high count on a fast server, it could indicate that that server is not the best candidate for virtualization.
• SystemContext Switches/sec. A context switch is when the processor swaps out the thread that it’s currently processing with another. Your processor does this all the time, as it’s a part of its ability to multitask. But, when this number is very high, that’s an indication of too many processes vying for attention of the processor. Where you usually see a high context switch count is on Terminal Servers or servers with very old applications. Because of the high process count on servers like Terminal Server and Citrix, they can sometimes not be good candidates for virtualization.
• SystemThreads. The thread count on a system directly relates to the number of things the processor needs to accomplish. Lots of threads potentially means lots of context switches to process them all. Like with high context switches, a high thread count can also mean a well-used processor and a suspect virtualization candidate.
• MemoryAvailable Mbytes. Unlike the other counters, a high Available Mbytes count can be a good thing. This means that your system isn’t using much of its installed RAM. Where this counter comes in handy is in right-sizing the RAM assigned to your virtual machines. Typical physical machines have too much RAM installed, which means much of it goes unused. This happens because RAM prices are cheap at the time you buy the server, but more expensive later on. So, many administrators over-spec their servers with high amounts of RAM.

In these metrics, you see numerous references to “virtualization.” With the release of Windows Server 2008, Microsoft very astutely began considering Terminal Services as a form of virtualization they call “Presentation Virtualization.” In the context of counters like these, the analogy holds true, as Terminal Services’ Presentation Virtualization counters are equally as useful as those used for determining candidacy with the more traditional hardware virtualization.

The easiest way to use these counters is as a mechanism for comparison. It is exceptionally difficult to give absolute numbers that will tell you when your server is fully loaded. The reason is that different servers and hardware configurations will see different absolute numbers. Thus, the best way to determine your user load is to look at these counters and relate them to the subjective opinions of your users and the quality they perceive of their user experience.

About the Author

Greg Shields is an independent author, speaker, and IT consultant, as well as a Partner and Principal Technologist with Concentrated Technology. With 15 years in information technology, Greg has developed extensive experience in systems administration, engineering, and architecture specializing in Microsoft OS, remote application, systems management, and virtualization technologies. He is a Contributing Editor and columnist for TechNet Magazine and Redmond Magazine, and serves as the Series Editor for Realtime Publishers, the world’s leading provider of high-quality content for the IT market. Greg is a highly sought-after and top-ranked speaker for both live and recorded events, and is seen regularly at conferences like TechMentor Events, Microsoft Tech Ed, VMworld, and more. He is a multiple recipient of Microsoft “Most Valuable Professional” award.