IIS and File Server Configuration Scenarios for SMB Scaling (IIS 6.0)

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

In order to determine the proper configuration for the IIS and file servers, let’s examine how the caching algorithms (last-modified time and file change notification) affect the aforementioned MaxCmds, MaxMpxCt, and MaxWorkItems registry settings. These considerations, in conjunction with performance monitor studies, can tell you how to best configure your servers. For the purpose of this discussion, each application is considered a UNC-mapped Web site or virtual directory.

In the following scenarios, assume that each server has more than 512 MB of RAM and that there are four IIS servers connecting the file server.

Scenario 1: Very Wide Content Low Traffic

In this scenario, each IIS server hosts up to 20,000 applications. Of those 20,000 applications, only 1,000 or so would be active at any given time. Each active site runs in its own application pool and has two users; a publishing user (using FrontPage or WebDAV publishing) and an anonymous user. The content is dominantly ASP and static files, with a small number of ASP.NET applications.

File-change notification algorithm

Using the formula given in “Estimating MaxCmds When Using File Change Notification,” the value for MaxCmds is estimated as follows:

20,000 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 60,000

Next, the maximum number of work items on the file server is calculated:

MaxWorkItems = (60,000 * 4 IIS servers) = 240,000 work items

Finally the nonpaged pool memory requirement on the file server is calculated as:

Nonpaged Pool = (60,000 * 4) * 20K ≈ 4.6 GB

The nonpaged pool memory requirement is larger than the 256 MB limit. In this scenario, there is not enough memory to use file change notification.

Last-modified time algorithm

Using the last-modified time method for cache updates, you would not use up any work items for change notifications. This is the default configuration, and as you can see from this analysis, is required for this scenario.

Using the formula given in “Estimating MaxCmds When Using File Change Notification”:

MaxCmds = ([1,000 for the peak number of requests] / [5 seconds for the staleness interval]) / 2 = 1,000

Next, calculate MaxWorkItems:

MaxWorkItems = (1,000 * 4 IIS servers) = 4,000

Finally the estimated nonpaged pooled memory required on the file server is calculated as:

Nonpaged Pool = 4,000 * 20K 80 MB

The nonpaged pool memory requirement is within the 256 MB limit.

Depending on active traffic for file I/O and your analysis of the performance counters (Server\Files Open, Server\Server Sessions, and Server\Work Item Shortages mentioned above), you may still need to increase the settings for MaxCmds, MaxWorkItems, and MaxMpxCt from your estimated values.

Conclusion

Recommended settings for Scenario 1, using the default last-modified time caching algorithm:

Registry Setting IIS Server File Server

MaxCmds

1,000

Default

MaxMpxCt

Default

1,000

MaxWorkItems

Default

4,000

This scenario works well where the large number of sites means that using the file change notification algorithm would prevent the configuration from scaling because there is insufficient nonpaged pool memory available. With SMB removed as a constraint to scaling, you should be sure to consider the aggregate traffic volume to the sites in addition to how adding more sites affects administrative burden, to determine how many sites you can configure per server in practice.

Scenario 2: Wide Content-High Traffic

This scenario discusses a large site with very high volume running several hundred applications; for this example, assume 300 applications. Also assume that this site contains static files, ASP content, and ASP.NET content, and that most of the users are anonymous users.

File-change notification algorithm

Using the formula given in “Estimating MaxCmds When Using File Change Notification”:

MaxCmds = 300 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 950

Next, the maximum number of work items on the file server is calculated:

MaxWorkItems = (950 * 4 IIS servers) = 3,800

Finally the estimated nonpaged pooled memory required on the file server is calculated as:

Nonpaged pool = 3,800 * 20K ≈ 76 MB

Last-modified time algorithm

You would not use any work items for last-modified time, but you would have many temporary work items in use due to the heavy traffic between the Web server and the file server. When using the last-modified time algorithm, caches in user mode are used, but the kernel-mode response cache is not. This results in a potentially significant increase in the volume of file traffic. Due to the heavy volume, the CPU overhead associated with checking the last-modified time algorithm for the three caches would be significant.

Conclusion

Recommended settings for Scenario 2, using the IIS change notification caching algorithm:

Registry setting IIS Server File Server

MaxCmds

950

Default

MaxMpxCt

Default

1,024

MaxWorkItems

Default

4,096

In this scenario, choosing the change notification algorithm is a good idea even though it results in more work items being used. Due to the high volume, it is better to reduce the amount of traffic to the file servers as much as possible. If using change notification, the number of directories to monitor is not going to exhaust memory and you significantly reduce back-end traffic. Traffic is reduced by eliminating the need to check the last-modified time on the file servers for every sampling interval and by using the HTTP.sys cache.

If, after implementing these settings, you find that there are too many applications to cache in this manner, you could use the last-modified time algorithm and extend the staleness time of the cache to 30 seconds, which would also dramatically reduce the amount of back-end network traffic.

Scenario 3: Narrow Content High Traffic

This scenario discusses a small site with 10 applications, consisting of static, ASP, and ASP.NET content that receives very frequent requests.

File-change notification algorithm

Using the formula given in “Estimating MaxCmds When Using File Change Notification”:

MaxCmds = 10 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 80

Next, the maximum number of work items on the file server is calculated:

MaxWorkItems = (80 * 4) = 320

Finally the estimated nonpaged pooled memory required on the file server is calculated as:

NonPagedPool = 320 * 20K ≈ 1.6 MB

Last-modified time algorithm

You would not use up any work items that are tied to change notifications, but you would have temporary work items and heavy traffic between the Web server and the file server.

In this scenario, it is easy to recommend using the file-change notification caching mechanism. Since the content is organized in just a handful of applications, we only need a few work items to reliably cache the content.

Note that MaxWorkItems is (MaxCmds * number of IIS servers) which is 80 * 4 = 320. This is well below the default value of 4,096 for MaxWorkItems, so this value does not need to be adjusted.

Additional Considerations

If the remote file server also delivers files to computers other than the IIS servers, you will need to increase the value of MpxCt and MaxWorkItems to allow for the additional connections. As a general rule, increase MpxCt by 50 for each connection to a different server. Include 25 to 50 percent of the increase in the value for MaxWorkItems.

It is important to note that MaxMpxCt, used in conjunction with MaxCmds, is what allows a single client to use more resources on a remote server than would otherwise be allowed, and thus can increase your exposure to a denial of service (DoS) attack from a malicious client.

Conclusion

Recommended settings for Scenario 3, using the IIS change notification caching algorithm:

Registry Setting IIS Server File Server

MaxCmds

80

Default

MaxMpxCt

Default

80

MaxWorkItems

Default

Default

For high traffic servers with only one or a few sites, SMB scale isn’t the primary factor affecting scale. Instead, you should tune the SMB and caching algorithm settings to optimize the efficiency of handling requests.

Reliability testing in Microsoft labs has found that adjusting these registry keys can produce dramatic differences in performance. However, testing your application with the defaults and then increasing the settings as appropriate is strongly recommended. You should also consult the SMB documentation in Windows, as well as read the related Knowledge Base articles that are listed in the appendix.