Dynamic Memory
Dynamic Memory enables more efficiently utilization of the memory resources of the server running Hyper-V by balancing how memory is distributed between running virtual machines. Memory can be dynamically reallocated between virtual machines in response to their changing workloads.
Dynamic Memory enables you to increase virtual machine density with the resources you already have without sacrificing performance or scalability. The result is more efficient use of expensive server hardware resources, which can translate into easier management and lower costs.
On guest operating systems running Windows 8 with virtual processors that span multiple logical processors, consider the tradeoff between running with Dynamic Memory to help minimize memory usage and disabling Dynamic Memory to improve the performance of an application that is computer-topology aware. Such an application can leverage the topology information to make scheduling and memory allocation decisions.
Tiered Storage
RD Virtualization Host supports tiered storage for a pooled virtual desktop collection. The physical computer that is shared by all pooled virtual desktops within a collection can use a small-size, high-performance storage solution, such as a mirrored solid-state drive (SSD). The pooled virtual desktops can be placed on less expensive, traditional storage such as RAID 1 0.
The physical computer should be placed on a SSD is because most of the read-I/Os from pooled virtual desktops go to the management operating system. Therefore, the storage that is used by the physical computer must sustain much higher read I/Os per second.
This deployment configuration assures cost effective performance where performance is needed. The SSD provides higher performance on a smaller size disk (20 GB per collection, depending on the configuration). Traditional storage for pooled virtual desktops (RAID 1 0) uses about 3 GB per virtual machine.
The Failover Clustering feature in Windows Server 2012 provides caching on Cluster Shared Volumes (CSV). This is extremely beneficial for pooled virtual desktop collections where the majority of the read I/Os come from the management operating system. The CSV cache provides higher performance by several orders of magnitude because it caches blocks that are read more than once and delivers them from system memory, which reduces the I/O.
For more information, see How to Enable CSV Cache.
Pooled Virtual Desktops
By default, pooled virtual desktops are rolled back to the pristine state after a user signs out, so any changes made to the Windows operating system since the last user sign-in are abandoned.
Although it’s possible to disable the rollback, it is still a temporary condition because typically a pooled virtual desktop collection is re-created due to various updates to the virtual desktop template.
Hence, it makes sense to turn off Windows features and services that depend on persistent state. Additionally, it makes sense to turn off services that are primarily for non-enterprise scenarios.
Each specific service should be evaluated appropriately prior to any broad deployment. The following is a “starting list” to consider.
Service
|
Why?
|
Auto update
|
Pool virtual machines are updated by re-creating the virtual desktop template.
|
Offline files
|
VDI virtual machines are always online and connected from a networking point-of-view.
|
Background defrag
|
File-system changes are discarded after a user signs off (due to a rollback to the pristine state or re-creating the virtual desktop template, which results in re-creating all pooled virtual desktops).
|
Hibernate or sleep
|
No such concept for VDI
|
Bug check memory dump
|
No such concept for pooled virtual desktops. A bug-check pooled virtual desktop will start from the pristine state.
|
WLAN autoconfig
|
There is no WLAN device interface for VDI
|
Windows Media Player network sharing service
|
Consumer centric service
|
Home group provider
|
Consumer centric service
|
Internet connection sharing
|
Consumer centric service
|
Media Center extended services
|
Consumer centric service
|
This list is not meant to be a complete list, because any changes will affect the intended goals and scenarios.
Note SuperFetch in Windows 8 is enabled by default. It is VDI aware, and it should not be disabled. SuperFetch can further reduce memory consumption through memory page sharing, which is beneficial for VDI.
Performance Tuning for Remote Desktop Gateway
Note In Windows 8 and Windows Server 2012, RDGW supports TCP, UDP, and the legacy RPC transports. Most of the following data is regarding the legacy RPC transport. If the legacy RPC transport is not being used, this section is not applicable.
This section describes the performance-related parameters that help improve the performance of a customer deployment and the tunings that rely on the customer’s network usage patterns.
At its core, the Remote Desktop Gateway (RD Gateway) performs many packet forwarding operations between Remote Desktop Connection instances and the RD Session Host server instances within the customer’s network.
Internet Information Services (IIS) and RD Gateway export the following registry parameters to help improve system performance in the RD Gateway role service.
Note The following parameters apply to RPC transport only.
Thread tunings
MaxIoThreads
HKLM\Software\Microsoft\Terminal Server Gateway\ (REG_DWORD)
This application-specific thread pool specifies the number of threads that RD Gateway creates to handle incoming requests. If the registry is present, it takes effect. The number of threads equals the number of logical processes. If the number of logical processors is less then 5, the default is 5 threads.
MaxPoolThreads
HKLM\System\CurrentControlSet\Services\InetInfo\Parameters
\(REG_DWORD)
This parameter specifies the number of IIS pool threads to create per logical processor. The IIS pool threads watch the network for requests and process all incoming requests. The MaxPoolThreads count does not include threads that RD Gateway consumes. The default value is 4.
Remote procedure call tunings for RD Gateway
The following parameters can help tune the remote procedure calls (RPC) that are received by RDC client and RD Gateway computers. Changing the windows helps throttle how much data is flowing through each connection and can improve performance for RPC over HTTP v2 scenarios.
ServerReceiveWindow
HKLM\Software\Microsoft\Rpc\ (REG_DWORD)
The default value is 64 KB. This value specifies the window that the server uses for data that is received from the RPC proxy. The minimum value is set to 8 KB, and the maximum value is set at 1 GB. If a value is not present, the default value is used. When changes are made to this value, IIS must be restarted for the change to take effect.
ClientReceiveWindow
HKLM\Software\Microsoft\Rpc\ (REG_DWORD)
The default value is 64 KB. This value specifies the window that the client uses for data that is received from the RPC proxy. The minimum value is 8 KB, and the maximum value is 1 GB. If a value is not present, the default value is used.
| 