我正在开发一个遗留应用程序，其中ASP.NET HttpHandler正在运行自己的线程池，该线程池加载自己的进程外COM对象实例。请求进入并将工作负载传递给这些COM对象，并在完成时返回结果。
处理工作正常，你肯定看到池正在工作，因为同时发出的请求可靠地处理...只要池线程数保持在10以下并且池没有饱和忙请求。一旦池既没有使COM请求饱和，也没有普通的ASP.NET Handler请求再次访问ASP.NET管道，直到池释放实例。
当我运行带有16个实例的线程池并用长时间运行（等待）请求命中服务器需要5秒才能完成时，我可以看到确实有10个实例加载了工作。除此之外的任何实例都不会被击中。不仅如此 - 即使是没有命中COM池的直接处理程序请求也会在此时开始排队。
更多信息：
我使用自定义线程池的原因是因为COM依赖性并且需要确保COM对象在没有COM编组的情况下保持在同一线程上加载。如上所述，它工作正常，直到所有实例都忙，然后一切都停止，直到池释放一个新实例。
我可以理解COM对象可能被阻止，但我真的不明白为什么主ASP.NET线程甚至无法处理原始处理程序请求（即我有一个运行简单响应的标志）。 Write（）响应并返回它并且它就像池请求饱和时的COM请求一样等待。
我怀疑它与COM对象实例化有关，但我很困惑，为什么在非ASP托管线程上创建对象时会发生这种情况。
有没有人看到这样的行为，ASP.NET根本不会创建新的请求线程而只是排队？
答案 0 :(得分：3)
客户端操作系统（例如Windows 7）上的IIS对并发连接数有限制。例如，请参阅http://forums.iis.net/p/1229666/2114928.aspx?Is+there+an+Concurrent+Request+Limit+on+IIS+8+5+。