In IIS 4.0, each Web site was bound to a different IP address. This meant each site had its own socket, which was not shared with sites bound to other IP addresses. These sockets are created when each site starts, and they can consume significant amounts of nonpaged memory (RAM). This memory consumption limits the number of sites bound to IP addresses that can be created on a machine, because, after a certain number of sites are started, the machine is out of RAM.
For IIS 5.0, this process was modified so that sites bound to different IP addresses—but sharing the same port number—share the same set of sockets. The end result is that more sites can be bound to an IP address on the same machine than in IIS 4.0. In IIS 5.1, these shared sockets are used flexibly among all of the started sites, thus reducing resource consumption.
This is now the default behavior for IIS versions 5.0 and higher. In general, this behavior should not be modified. However, for critical sites that require a dedicated socket, you can set the DisableSocketPooling to TRUE to revert back to the IIS 4.0 behavior. This change should be made at the site level only, so that other sites can continue to take advantage of the new socket pooling feature.
You might want to disable socket pooling if any of the following are true:
Socket pooling causes IIS 5.1 to listen to all IP addresses, which may present a security risk for secure domains with multiple networks. In addition, both bandwidth throttling and performance adjustments apply to all Web sites configured for the same port, for example port 80. If you intend to use bandwidth throttling or do performance tuning on a per-site basis, each site must have its own IP address, and you need to disable socket pooling. Web sites that use Host Headers cannot be tuned individually.
To disable socket pooling, type the following at the command prompt:
c:\inetpub\adminscripts\cscript adsutil.vbs set w3svc/disablesocketpooling true
The command prompt replies:
disablesocketpooling : (BOOLEAN) True