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

我正在使用传统的ASP Classic解决方案,它是负载平衡的(通过外部硬件,并且有一个IIS站点,其主目录是UNC路径.我被告知目前存在以下问题:

当使用UNC路径作为主目录时,IIS中的某个"索引"会"缓存"某些类型的某些文件,并且当达到默认值为50的限制时,后续请求不在缓存中的页面将返回404.

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

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

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

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

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

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

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

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

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

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

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