I see a lot of deployments of XenApp and / or Terminal Services on 32 bit systems, typically Windows Server 2003 R2 and, while its old hat, I thought it’s still worth taking a few minutes to make a note of the correct settings for optimisation of RAM and CPU in a thin client environment. When you first install Windows Server 2003 R2 the default performance settings for RAM and CPU before the operating system has had a role assigned are as below:

Once the Terminal Services Role has been installed these are changed to:

At a very basic level, these are the correct settings to use. But why ? For CPU, this forces the CPU to allot less time to a task before switching between tasks. In a service based environment (for SQL or Exchange for example) the CPU should be optimised for services so that the CPU allots more time to a single task before switching to any different task requiring processor time. As servers hosting services tend to have multiple cores this reduces context switching and results in higher performance for long running tasks.

In a thin client environment where multiple users are competing for processor time perceived performance is enhanced if the processor provides some time to each user. That is, if it can switch between threads more quickly. To do this, we optimise for programs in the GUI.

Regarding memory, the limiting factor in a 32 bit thin client server based computing environment is not necessarily user RAM but, more often, paged pool RAM and non-paged pool RAM. These are limited to around 650MB and 256MB respectively (for Windows Server 2003 – these limits have been removed somewhat in Windows 2008). These limits also hold true for Windows Server 2003 r2 Enterprise Edition. The server may have 32GB of RAM, for example, but will still have these small amounts of RAM available for end user tasks. If we optimise the RAM for programs then this reduces the amount of RAM available for these system type processes … the above figures are reduced still further. As paged pool RAM is consumed the server may start to page, even though there is ample spare user RAM. Even more concerning, if non-paged pool RAM is depleted this cannot be paged and, in the worst case, the server may even blue screen.

I hope the above brings some understanding as to why the above are the default settings. Some items to bear in mind:

1. Mark Russinovich has an excellent article on RAM which applies to thin client environments at http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx
2. Jeremy Saunders has written an outstanding article on Processor Scheduling at http://www.jhouseconsulting.com/2008/05/13/processor-scheduling-20
3. RAM can be set to use prefer System Cache by setting the key HKLMSYSTEMCurrentControlSetControlSession ManagerMemory ManagementLargeSystemCache to 1
4. Processor Scheduling can be further optimised by setting the key HKEY_LOCAL_MACHINESystemCurrentControlSetControlPriorityControlWin32PrioritySeparation to 40

Why do people change these settings to the exact opposite of the defaults ? I have no idea but hope that someone can enlighten me.