我正在使用一个旧式ASP Classic解决方案，该解决方案是负载平衡的(通过外部硬件，并且具有一个IIS站点，该站点的主目录是UNC路径。有人告诉我，此设置当前存在以下问题：

• 当使用UNC路径作为主目录时，IIS中的某个地方有一个"索引"，可以"缓存"多达一定数量的某些类型的文件，并且在达到默认值50的限制后，不在缓存中的页面将返回404.
• 当使用UNC路径作为主目录时，启动IIS站点时，上述"缓存"将开始填充，这将使站点IIS陷入困境，直到缓存被填充为止，这意味着无法使用庞大的站点(15,000个.asp文件)。 IIS站点启动后最多30分钟。
• 当使用UNC路径作为主目录时，如果对该站点同时进行的请求数量超过一定数量，则Windows将达到"每台服务器的网络BIOS命令限制"，并且所有超过该限制的请求都必须等到" IIS"关闭会话"。我被告知限制为100个文件且不可配置。

现在，所有这些听起来有点怪异。如果我使用默认设置设置了一个新的Windows 2003 Server，并使用它来承载包含15,000个.asp文件的ASP Classic应用程序，并使用服务器上的共享作为IIS站点的主目录，则实际上会遇到这些问题？如果是这样，有没有办法在不改变体系结构的情况下应对它们？

(为澄清起见，"负载平衡"重要的唯一原因是负载平衡是文件位于服务器共享上的原因。如果不需要负载平衡，则文件可以位于本地磁盘上。)

解决方案

对于答案3，我们可以更改网络BIOS命令限制。它是一个非常简单的注册表编辑修复程序：http://support.microsoft.com/kb/810886/zh-cn

我本人也遇到了这个问题。

我不确定我们对IIS和UNC之间的交互的直接问题，但是我建议在繁忙的站点(繁忙到需要负载平衡的任何地方)，我们都考虑使用文件共享以外的其他方法。

由IIS跨网络加载的asp(即文件共享)将对性能产生负面影响(延迟)。

我建议使用robocopy之类的方法来使所有负载平衡的服务器与中央主机保持同步。换句话说，部署到单个主服务器(或者单个主位置)，然后将文件自动复制到负载平衡器池中的每个从属服务器。

这不仅可以消除我们描述的UNC异常问题，而且还可以提高性能(通过消除加载asp页时的网络点击)。如果我们这样做，我希望性能会大大提高。

是的，有可能，但是是的，这可能会引起问题。

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

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

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

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

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

最后，我们必须进行测试以查看站点是否足够小以及NetBIOS设置是否足够高以有效运行。我建议在测试站点上使用Spider，这样可以确保可以编译或者访问的所有内容至少一次。