Windows Server Update Services 3.0 SP2 Deployment Guide Abstract

Supported Capacity by Configuration

Additional hardware and database requirements depend on your how your organization implements WSUS 3.0 SP2 and your performance expectations. The following table shows performance data for the maximum number of supported clients in two sample configurations: one for NLB and one for a single server implementation. The table includes test specifications and results that were achieved in the Microsoft test lab. You can use this data as a guideline to develop your own test scenarios and to make your hardware and software decisions.

Be aware that your organization’s performance results may vary if you choose to use different hardware; however, the maximum supported capacity figures do not change. That is, if you use a higher performance server than indicated in the table that follows, there may be an increase in the number of client synchronizations per second. However, there is no increase in the maximum number of supported clients for the configuration.

Sample Configurations and Maximum Supported Capacity

Configuration

2 FE servers and one

BE server in an NLB configuration

Maximum Supported Hardware and

Capacity Software

100K clients

Client

Synchronizations

and Updates

Hardware

 FE: Intel Core 2

CPU 6400, 2.13

GHz, 4GB RAM

 BE: 8x AMD

Opteron

Processor 850,

2.2 GHz, 32GB

RAM

Software

 FE: Win2K3

Standard x86 SP2

 BE: Win2K3

Standard x64

SP1, SQL 2005

SP2

SUSDB files (data and log) on separate physical disks each with

200+ GB free space

Delta sync at 7.5 hour frequency

Avg. requests per client:

30

Transaction rate: 3 clients per second

CPU avg. usage: FE

27%, BE 16%

26

Configuration Maximum Supported Hardware and

Capacity Software

Client

Synchronizations

and Updates

Single server, non-

NLB

25K clients Hardware: Intel Core

2 Quad CPU Q6600,

2.40 GHz, 4GB RAM

Software: Win2K3

Standard x64 SP2

Delta sync at 1 hour frequency

Avg. requests per client:

10

Transaction rate: 6 clients per second

CPU avg. usage: 21%

Performance notes:

 Transaction rate is defined as the time needed to service a single client, which includes multiple requests.

 Performance testing was done by using delta sync requests. Be aware that an initial request to the server (a full sync) will generate a server CPU spike, as the server needs to build up its internal caches.

 If WSUS clients synchronize with the server more frequently than is shown in the table, there will be a corresponding increment in the server load. For example, if clients synchronize every 4 hours in an NLB configuration, the load will be two times as much as an 8 hour synchronization frequency. Be aware that the Group Policy setting that specifies the number of hours that Windows uses to determine how long to wait before checking for available updates automatically staggers the requests to the server. The exact wait time is determined by using the hours specified minus zero to 20 percent of the hours specified. For example, if this policy is used to specify a 20 hour detection frequency, then all clients to which this policy is applied will check for updates anywhere between 16 and 20 hours. Requests are processed first-in, first-out. If the number of concurrent sync requests exceeds capacity, they are placed in the IIS queue until they can be processed.

 Increasing the number of languages will also increase the server load. Updating in five languages, instead of one language will approximately double the size of the content directory.

 Using the WSUS Admin console to run reports during the client sync process had no noticeable effect on performance.

Install the WSUS 3.0 SP2 Server

After designing the WSUS deployment, you are ready to install the WSUS server component.

Use the five topics listed below to prepare the computer and the network environment for WSUS.

Check hardware and software requirements (as noted in the Determine WSUS Capacity

27