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

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

当使用UNC路径作为主目录时，IIS中的某个位置有一个“索引”，该索引“缓存”最多一定数量的特定类型的文件，当达到该限制（默认为50）时，对不在缓存中的页面的后续请求将返回404

当使用UNC路径作为主目录时，启动IIS站点时，前面提到的“缓存”将开始填充，这将使站点IIS陷入停滞，直到缓存被填充，这意味着在IIS站点启动后，大型站点（15000.asp文件）最多30分钟不可用

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

现在，所有这些听起来有点奇怪。如果我用默认设置设置了一个新的Windows 2003服务器，并使用它来托管一个包含15000个.ASP文件的ASP经典应用程序，使用服务器上的共享作为IIS站点的主目录，我真的会遇到这些问题吗？如果是，有没有办法在不更改arc的情况下解决这些问题H体系结构？

---

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

对于答案3，您可以更改网络BIOS命令限制。这是一个非常简单的注册表编辑修复程序：

---

<>我自己也遇到过这个问题。

我不确定你直接问IIS和UNC之间的交互问题，但是我建议在一个繁忙的站点（任何繁忙的事情都需要负载平衡），你考虑的不是文件共享。 IIS跨网络（即文件共享）加载的asp将受到负面性能影响（延迟）

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

---

这不仅可以消除您描述的wierd UNC问题，还可以给您带来不错的性能提升（通过删除加载asp页面时遇到的网络问题）。如果您这样做，我预计性能会有相当大的提升。

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

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

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

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

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

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

---

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

是的，我同意。实际上，我更喜欢DFS而不是RoboCopy-更多配置，不过，像往常一样，外部因素决定了这种特殊的设置。最终，在调整了NetBIOS限制等之后，一切都顺利运行。事实证明，FileSystemWatchers和ASP编译的启动延迟是可以忍受的。