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服务器，并使用共享服务器上的共享作为IIS站点的主目录来托管具有15,000个.asp文件的ASP Classic应用程序，我是否真的会遇到这些问题？如果是，有没有一种方法可以在不更改架构的情况下解决这些问题？ （澄清一下，负载平衡很重要的唯一原因是负载平衡是将文件放在服务器共享上的原因。如果不需要负载平衡，则文件可以位于本地磁盘上。）

- bzlm

Answer 1

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

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

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

通过注册表可以将NetBIOS限制设置得高于其默认值，但只能到达一定程度。

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

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

最终，你必须测试以确定你的站点是否足够小，你的NetBIOS设置是否足够高效。我建议在测试站点上使用爬虫，以确保至少可以编译或访问的所有内容。

- David

---

最终，在调整了NetBIOS限制等之后，一切都运行顺畅。FileSystemWatchers和ASP编译的启动延迟被证明是可以容忍的。 - bzlm

Answer 2

我不确定你对IIS和UNC之间的交互有什么直接的问题，但是我建议在一个繁忙的站点（任何需要负载平衡的繁忙站点）上，你应该考虑使用除文件共享以外的其他东西。

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

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

这不仅可以消除你所描述的奇怪的UNC问题，还应该为你提供一个良好的性能提升（通过消除加载asp页面时的网络开销）。如果你这样做，我预计会有相当大的性能提升。

- therealhoff

---

是的，我同意。实际上，我更喜欢DFS而不是RoboCopy——需要更多的配置，但可以减少失眠的夜晚。不过，通常情况下，外部因素决定了这个特定的设置。 - bzlm

Answer 3

对于第三个问题，您可以更改网络BIOS命令限制。这是一个相当简单的注册表编辑修复方法：http://support.microsoft.com/kb/810886/en-us

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

- Gthompson83