IIS7集成与经典管道-哪个使用更多ASP.NET线程？

通过集成管道，所有请求都通过ASP.NET传递，包括图像、CSS

然而，在经典管道中，默认情况下，只有对ASPX页面的请求才通过ASP.NET传递

集成管道是否会对线程使用产生负面影响

假设我从IIS服务器请求500 MB二进制文件：

• 通过集成管道，ASP.NET 将使用工作线程 下载二进制文件（对吗？）
• 对于经典管道，请求是 直接由IIS提供服务，因此没有ASP.NET 使用螺纹

对我来说，这有利于经典管道，因为我希望尽可能多的线程服务于ASPX页面

---

我在这里完全偏离了底线吗？

我想说你是对的，但我会从另一个角度来看待它

您是否需要处理非ASPX页面的请求？例如，记录它们，或者在不满足某些条件时禁止响应

---

如果您需要此处理功能，请使用集成管道。如果不这样做，请使用经典管道。

如果查看IIS 7中的machine.config、web.config和applicationHost.config，可以看到在经典管道和集成管道之间切换时，静态内容的服务方式不会改变。唯一改变的是映射到asp.net的请求是通过托管模块还是本机ISAPI筛选器模块传递

唯一可能影响性能的事情是，在处理静态内容请求时，修改授权模块和添加以执行的任何自定义模块的默认设置。即使在这里，开销也可以忽略不计

---

因此，一个更合适的基准应该是IIS 6与IIS 7，我怀疑IIS 7将是明显的赢家。

我需要提供静态内容：CSS、JS、JPG、PNG等。这些（尤其是图像）比ASPX页面内容占带宽的百分比更大。但是您需要.NET代码对这些静态内容进行任何处理吗？不，但我在这里的假设是，使用集成管道将导致静态内容由ASP.NET交付，而不是直接由IIS交付。这也是我理解它的方式，也是我试图在回答中解释的：-）使用经典管道模式。在IIS7中，ASP.NET和IIS的组合方式使得“由ASP.NET交付，而不是直接由IIS交付”不再有什么意义了。在IIS6中，IIS使用ISAPI模块将请求转发到ASP.NET运行时，而在IIS7中，ASP.NET是一等公民，您不再有这种开销。正如Chris Eldredge指出的，关于静态文件，没有区别。