UNC 共享 : is it problematic? 上的 IIS 站点

Question

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

当使用 UNC 路径作为主目录时，IIS 中的某处有一个“索引”，它“缓存”多达一定数量的某些类型的文件，并且当达到默认为 50 的限制时，后续请求不在缓存中的页面将返回 404。

当使用 UNC 路径作为主目录时，当启动 IIS 站点时，前面提到的“缓存”将开始填充，这将使站点 IIS 陷入困境，直到缓存被填充为止，这意味着大型站点(15,000 个 .asp 文件)不可用IIS 站点启动后最多 30 分钟。

当使用 UNC 路径作为主目录时，如果同时向站点发出超过一定数量的请求，Windows 将达到“每台服务器的网络 BIOS 命令限制”，所有超过该限制的请求都必须等到 IIS ”关闭 session ”到服务器。我被告知限制为 100 个文件且不可配置。

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

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

Answer 1

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

ASP.NET 在将 ASPX、ASCX 等内容页面编译成程序集时，会创建大量的 FileSystemWatcher 来监控它们之间的依赖关系，以便在文件发生变化时重新编译。这些会占用 NetBIOS 资源。

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

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

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

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

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