Hosting IIS with UNC content - Network BIOS commands and other errors
IIS and UNC - everyone wants to know more. The ASP.NET 2.0 Deployment Guide already talks about configuring ASP.NET over UNC. So now, let's explore SMB work contexts and how they are a huge factor for IIS/UNC configurations.
Between two Windows server, one SMB connection is opened. Within that connection there are a number of work items or contexts that are used. These registry keys control the number of work contexts permitted within that connection.
Translation: A web site has a remote file share as the home directory path. IIS receives file change notifications so that if a file changes, IIS is aware of it and could un-cache and re-read the files, for instance. This consumes a work context.
Now let's say there are hundreds or thousands of folders. Or hundreds to thousands of web sites. The default on Windows Server 2003 is fairly low and will soon run out of work contexts. This results in the error "The network BIOS command limit has been reached."
The fix? There's a registry key. By default it is set fairly low but the maximum is in the area of 65,000. And why not just set it to the maximum? The catch is that each of these work contexts consumes non-paged pool (NPP).
And now it gets (more) complicated... :-)
On the x86 platform, the non-paged pool limit is only 256MB, so you could run out of non-paged pool fairly quickly (to learn about NPP see KB 294418). If you set the registry key too high, you run out of non-paged pool and the server becomes unstable. If it's too low, you start seeing the error messages. This KB recommends a limit of 2,048, and this does seem to be a reasonable limit for 2,000+ web sites. If the sites are very busy, this may not be enough contexts.
On the x64 platform, the limit is 128GB so you can probably set the registry key to 65K and not worry quite so much about non-paged pool issues. Another handy factoid... in Wow64 mode the NPP limit is still 128GB. Sweet!
Keep in mind that you need to set the registry key on the file server as well, if it's running Windows. If you have multiple IIS web servers connecting to 1 file server, you're going to have 3 times the work contexts on the file server.
ASP.NET and File Change Notifications
Some other things to consider. One is that ASP.NET uses more notifications than html/static or classic ASP files. ASP.NET has to monitor a lot of files for an application, like Web.config, Global.asax, etc. Given a file to monitor, it creates a directory monitor for the folder containing the file. It will not monitor recursively (subdirectories). So if you have files in many different directories, you get a bunch of directory monitors. Each directory monitor is an SMB work item.
So the ASP.NET team released a QFE to help out. The KB discusses different behaviors that are possible, from turning off file change notifications (meaning you have to build some other way of monitoring for changes or you need to unload the app on changes) to using a single monitor for the root of an application and all subdirectories. Check out http://support.microsoft.com/?id=911272 for more details.
This post is based on the following resources:
- The registry keys and info described in KB 221790.
- This article (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx#EGAA) describing how to configure IIS with remote content.
- This article about dense hosting. The section titled "Windows-based Remote Content Store" has some good information about how this works. It points out additional info like the fact that some operations (such as monitoring for a file change notification) will be around for as long as the SMB connection is maintained. Other operations are temporary and don’t hold onto the work context.
Questions?