In this article in our Tuning Windows 2012 Server, we’ll look at ways to optimize the Remote Desktop Session Host, formerly “Terminal Server.” The key factors that affect the number of users and their experience are CPU, memory, disk, and graphics. The information in this article is mostly relevant to the multiuser environment of RD Session Host servers.
CPU configuration is conceptually determined by multiplying the required CPU to support a session by the number of sessions that the system is expected to support, while maintaining a buffer zone to handle temporary spikes. Multiple logical processors can help reduce abnormal CPU congestion situations, which are usually caused by a few overactive threads that are contained by a similar number of logical processors.
Therefore, the more logical processors on a system, the lower the cushion margin that must be built in to the CPU usage estimate, which results in a larger percentage of active load per CPU. One important factor to remember is that doubling the number of CPUs does not double CPU capacity.
The 64-bit processor architecture provides a significantly higher kernel virtual address space, which makes it more suitable for systems that need large amounts of memory. Specifically, the x64 version of the 64-bit architecture is a good option for RD Session Host deployments because it provides small overhead when it runs 32-bit processes. The most significant performance drawback when you migrate to 64-bit architecture is significantly greater memory usage.
It makes sense that the memory configuration depends on the applications that remote users employ, but you can estimate the required amount of memory by using the following formula:
TotalMem = OSMem + SessionMem * NS
OSMem is how much memory the operating system requires to run (such as system binary images, data structures, and so on), SessionMem is how much memory processes running in one session require, and NS is the target number of active sessions. The amount of required memory for a session is mostly determined by the private memory reference set for applications and system processes that are running inside the session. Shared code or data pages have little effect because only one copy is present on the system.
One interesting observation (assuming the disk system that is backing up the page file does not change) is that the larger the number of concurrent active sessions the system plans to support, the bigger the per-session memory allocation must be. If the amount of memory that is allocated per session is not increased, the number of page faults that active sessions generate increases with the number of sessions, and these faults eventually overwhelm the I/O subsystem. By increasing the amount of memory that is allocated per session, the probability of incurring page faults decreases, which helps reduce the overall rate of page faults.
Storage seems to be one of the most overlooked aspects when configuring an RD Session Host system, and it can be the most common limitation in systems. The disk activity that is generated in a typical RD Session Host system affects the following areas:
- System files and application binaries
- Page files
- User profiles and user data
Ideally, these areas should be backed up by distinct storage devices. Using striped RAID configurations or other types of high-performance storage further improves performance. Smart system administrators will use storage adapters with battery-backed write caching. Controllers with disk write caching offer improved support for synchronous write operations. Because all users have a separate hive, synchronous write operations are significantly more common on an RD Session Host system. Registry hives are periodically saved to disk by using synchronous write operations. To enable these optimizations, from the Disk Management console, open the Properties dialog box for the destination disk and, on the Policies tab, select the Enable write caching on the disk and Enable advanced performance check boxes.
If you need more specific information about tuning your storage, see our article “Tuning Windows 2012 – Performance Tuning Storage Subsystem.”
Lastly, we’ll look at network usage. This included two main categories:
- RD Session Host connections traffic in which usage is determined almost exclusively by the drawing patterns that are exhibited by the applications running inside the sessions and the redirected devices I/O traffic. For example, applications handling text processing and data input consume bandwidth of approximately 10 to 100 kilobits per second, whereas rich graphics and video playback cause significant increases in bandwidth usage.
- Back-end connections such as roaming profiles, application access to file shares, database servers, e-mail servers, and HTTP servers. The volume and profile of network traffic is specific to each deployment.
In part 2 of this article we’ll discuss Tuning Applications specifically for RD Host Sessions.