Optimizing Performance and Scalability

Applies To: Windows Server 2008, Windows Server 2008 R2

This chapter includes guidelines, techniques, and best practices to maximize performance, scalability, and reliability. Among other useful information, you will find techniques to identify blockages in your deployment, such as issues with network and server performance.

In This Topic

• Best Practices for Avoiding Performance and Scalability Problems

• Configuring the Server for Performance and Scalability

• Performance and Scalability Expectations

  • Unicast Installation

  • Multicast Installation

  • Security Options

  • TFTP Block Size

For information about analyzing blockages during an installation, see Troubleshooting Performance Problems.

Best Practices for Avoiding Performance and Scalability Problems

The following are best practices that you can use:

• Implement multicasting. When you deploy an image using multicasting, the image is sent over the network only once to all clients who have requested the image, which can drastically reduce the amount of network bandwidth that is used. If your server is running Windows Server 2008 R2, you can also use multiple stream transfer, which separates slower clients into their own multicast stream—enabling faster clients to complete their deployment more quickly instead of being held back by slower clients. For more information about multicast deployments, see Performing Multicast Deployments (https://go.microsoft.com/fwlink/?LinkId=89225).

• Ensure that the network interface between the server and client has sufficient bandwidth. Consider gigabit network adapters on the physical server with Category 5e (Cat 5e) cabling to a switch that can handle a GB back-plane connection, with 100-MB ports on the front-plane (100 MB-clients, 1-GB back end to the server).

• Use high-quality Ethernet cabling. We recommend at least Cat 5 or Cat 5e is recommended throughout the physical network.

• Use network switches. Do not use a hub.

• Partition network segments to distribute the load across multiple servers.

• Keep network latency to a minimum to optimize TFTP transfers.

• Ensure that the disk that contains the RemoteInstall folder has enough throughput to meet the client demand. On small-scale solutions, this may mean getting a Serial Advanced Technology Attachment (SATA) drive that spins at 7,200 RPM or faster. On mid-scale solutions, this may mean getting multiple drives and configuring them using Redundant Array of Independent Drives (RAID) configuration. On large-scale solutions, this may mean investing in a hardware RAID array. The disk volume that contains RemoteInstall should be separate from the system volume.

• Ensure that there is sufficient memory on the server to handle the demands. This may mean upgrading a server from 32-bit (x86) to 64-bit (x64). (for details about how to evaluate whether this solution is worthwhile for you, see Performance and Scalability Expectations).

• Ensure that there is enough processor bandwidth on the server to handle the demands. If the server has a lot of processes or services that are running, you may need to distribute the processes and services or upgrade the server’s processor.

Configuring the Server for Performance and Scalability

Performance is the speed of a single client installation. In tests, Windows Deployment Services performs on par with a network-based installation from a file share. As expected, factors such as image size, network speed, and disk speed on the client affect the installation times. Typical installations using the standard Windows Vista image took around 20 minutes from first client boot to desktop.

A key benefit of using Windows Deployment Services is the ability to deploy to several clients simultaneously. Again, many factors influence the solution's ability to scale, but the most important ones are the following (in order from most to least influential):

1. Network bandwidth. Windows Deployment Services performs best using a 1-GB-per-second network adapter. In tests, a server with a 100-MB-per-second network adapter could perform a maximum of 10 simultaneous installations, while keeping the installation time under an hour (regardless of the server RAM, disk speed, or processor speed). By contrast, a high-end server with a 1-GB-per-second network adapter could install Windows images on 75 simultaneous clients in 45 minutes.

2. RAM on the server. If the computer has enough available memory, it is possible to cache an entire image into memory. This reduces the number of disk read/write operations and, in turn, speeds up the process. If several different images are being deployed concurrently, you may need more RAM.

3. Disk speed on the server. Disk speed is another factor that can slow down deployments (even when you have the maximum amount of RAM). The install image must be read from the disk at least once, and a faster disk speed can accelerate this process.

4. Disk speed on the client. A blockage in the client computer's disk may keep it from achieving the shortest possible installation times.

Performance and Scalability Expectations

Microsoft performed tests to compare the installation times of multicast and unicast transmissions using the same hardware, software, and image set. The following table outlines the configurations of the servers and clients that were used during these tests. The boot and install images were taken from an x86-based version of Windows Server 2008. The size of the boot image was approximately 128 MB, and the size of the install image was approximately 1.32 GB. Note that the out-of-box experience (OOBE) and logon were automated by using an unattend file.

Multicast Installation

Unicast Installation

Security Options

The following table lists the times for the start and end of the multicast transfer of the install image, and the percentage of the CPU used for the multicast transfer, depending on the level of security that was enabled during the test. This test involved 25 client computers.

The following table outlines the hardware configurations of the servers that were used during these scalability tests.

TFTP Block Size

The following table shows the effect on time (in seconds) of changing the default TFTP block size. The times are cumulative for the total number of clients simultaneously downloading the same boot image.