Export (0) Print
Expand All

Optimizing Performance and Scalability

Updated: May 8, 2008

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.

For information about analyzing blockages during an installation, see Troubleshooting Performance 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 (http://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.

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.

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.

 

  Network interface card Hardware configuration Operating system

Server

1-Gbps network adapter

  • Dual Xenon processor 5150

  • 2.67 Ghz

  • 8 GB of RAM

  • 64-bit version of Windows Server 2008

Client

100 megabits network adapter

  • Varied but capable of installing the x86-based version of Windows Vista

  •  

 

  25 clients 100 clients 300 clients

 

Restart computer and start clock.

Restart computer and start clock.

Restart computer and start clock.

Time when the first client started download of boot image using TFTP

:23

:21

:23

Time when the last client finishes download of boot image using TFTP

1:02

2:40

7:16

Time when the first client started the multicast transfer

3:04

3:55

8:18

Time when the last client finished the multicast transfer

6:06

7:54

12:30

Total amount of time until the last client reached the desktop

19:47

22:40

27:40

 

  SMB 25 clients SMB 100 clients SMB 300 clients

 

Restart computer and start clock.

Restart computer and start clock.

Restart computer and start clock.

Time when the first client started download of boot image using TFTP

:21

:22

:20

Time when the last client finished download of boot image using TFTP

:58

2:40 

7:13

Time when the first client started image transfer using unicast/SMB

3:14

4:38

8:29

Time when the last client finished image transfer using unicast/SMB

13:36

38:15

1:47:58

Total amount of time until the last client reached the desktop

20:59

45:37

1:55:15

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.

 

  No Security Hashing (default) Signing

Start of multicast transfer of the install image to the client

Clock started

Clock started

Clock started

End of multicast transfer of the install image to the client

2:19

2:27

31:05

Percentage of CPU used during the multicast transfer

~5%

~11%

~25%

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

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.

 

Network adapter Number of clients Default 4,000 8,000 16,000 32,000

GB

50

270

180

118

92

85

GB

75

422

267

171

126

125

100 MB

75

1,410

 

 

1,140

 

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft