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