UNC共享的IIS站点：它有问题吗？

Question

我正在使用传统的ASP Classic解决方案，该解决方案是负载平衡的（通过外部硬件并且有一个IIS站点，其主目录是UNC路径。我被告知此设置目前存在以下问题：

1. 当使用UNC路径作为主目录时，IIS中某处有一个“索引”可以“缓存”某些类型的特定数量的文件，并且当达到限制（默认为50）时，对不在缓存中的页面的后续请求将返回404。
2. 当使用UNC路径作为主目录时，启动IIS站点时，前面提到的“缓存”将开始填充，这将使站点IIS陷入困境，直到缓存被填满，这意味着巨大的站点（15,000 .asp文件） IIS站点启动后最多30分钟不可用。
3. 当使用UNC路径作为主目录时，如果对站点发出超过一定数量的同时请求，Windows将达到“每个服务器的网络BIOS命令限制”，并且所有超出限制的请求将必须等待直到IIS“关闭会话”到服务器。我被告知限制是100个文件，不可配置。

现在，这一切听起来有点奇怪。如果我使用默认设置设置新的Windows 2003服务器，并使用它来托管具有15,000个.asp文件的ASP Classic应用程序，使用服务器上的共享作为IIS站点的主目录，我将实际运行陷入这些问题？如果是这样，有没有办法在不改变架构的情况下对付它们？

（澄清一下，“负载平衡”很重要的唯一原因是负载平衡是文件在服务器上共享的原因。如果不需要负载平衡，文件可能在本地磁盘上。 ）

Answer 1

是的，这是可能的，但是，它可能会导致问题。

当ASP.NET将ASPX，ASCX和其他内容页面编译成程序集时，它会创建许多FileSystemWatchers以监视它们之间的依赖关系，以便在文件更改时可以重新编译。这些占用了NetBIOS资源。

此外，每次对站点的服务路径执行File.Exists或Directory.Exists调用或任何其他类型的IO时，都会增加对NetBIOS限制的要求。

可以通过注册表将NetBIOS限制设置为高于其默认值。

对于一个目录和文件相对较少的小型站点，您可以非常成功地运行UNC共享，因为ASP.NET将在启动其编译的程序集后继续运行。但是，添加的目录和文件越多，出现问题的可能性就越大。

我们尝试运行一个庞大的站点（数百个目录和ASPX / ASCX文件），它可以正常运行几分钟，直到访问了足够的URL以达到NetBIOS限制，然后每个后续页面视图都导致异常。我们最终被迫使用robocopy发布解决方案。

最后，您必须进行测试，看看您的网站是否足够小，并且您的NetBIOS设置足够高以便有效运行。我建议在测试网站上使用蜘蛛，以便您可以确保所有可以编译或访问的内容至少一次。

Answer 2

我不确定您对IIS和UNC之间的交互的直接问题，但我建议在繁忙的站点（任何忙于足以要求负载平衡的东西），您考虑的不是文件共享。

IIS通过网络（即文件共享）加载的asp将受到负面的性能影响（延迟）。

我建议使用robocopy之类的东西来保持所有负载均衡的服务器与中央主服务器同步。换句话说，部署到单个主服务器（或单个主服务器位置），然后将文件复制到负载均衡器池中的每个从服务器。

这不仅会删除您描述的奇怪的UNC问题，还应该为您提供良好的性能提升（通过在加载asp页面时删除网络命中）。如果你这样做，我会期待相当大的性能提升。

Answer 3

对于答案3，您可以更改Network BIOS命令限制。它是一个非常简单的注册表编辑修复：http://support.microsoft.com/kb/810886/en-us

我自己也遇到了这个问题。