ASP.NET处理程序、手动线程和COM服务器

Question

我正在开发一个遗留应用程序，其中一个ASP.NET HttpHandler正在运行自己的线程池，该线程池加载自己的进程外COM对象实例。请求将传入并将一个工作负载传递给这些COM对象，并在完成后返回结果。

处理工作正常，您肯定看到池正在工作，因为同时传入的请求是可靠处理的.只要池线程数保持在10以下，并且池没有被繁忙的请求填满。一旦池既不满足COM请求，也不满足普通的ASP.NET处理程序请求，就会再次访问ASP.NET管道，直到池释放一个实例为止。

当我使用16个实例运行线程池，并以5秒时间完成的长时间运行(等待)请求访问服务器时，我可以看到正好有10个实例加载了工作。任何超过这一点的例子都不会被击中。不仅如此--甚至没有命中COM池的直接处理程序请求也在此时开始排队。

更多信息：

• COM池是用MTA线程创建的(但是STA不会改变任何东西)
• COM对象是STA线程和进程外的EXEs。
• COM对象在其上创建的固定线程上执行(即。没有COM线程编组)
• ASP.NET线程向池线程发出信号以启动处理
• 当前，ASP.NET上下文被传递给池线程。
• 运行.NET 4.5
• Windows 10 Pro上的测试

我之所以使用自定义线程池，是因为COM依赖关系，以及需要确保COM对象在没有COM编组的情况下继续加载在同一个线程上。如前所述，它可以正常工作，直到点被所有实例都繁忙为止，只有到池释放一个新实例时，一切才会停止。

我可以理解COM对象可能会被阻塞，但我真的不明白为什么主ASP.NET线程甚至不能处理原始的处理程序请求(即。我有一个标志，它运行一个普通的Response.Write()响应并返回，它就像池饱和时的COM请求一样，处于等待状态)

我怀疑这与COM对象实例化有关，但我很困惑为什么在非ASP托管线程上创建对象时会发生这种情况。

有没有人看到过这样的行为: ASP.NET根本不会创建新的请求线程和简单的队列？

Answer 1

客户端操作系统(例如Windows 7)上的IIS对并发连接的数量有限制。例如，请参见http://forums.iis.net/p/1229666/2114928.aspx?Is+there+an+Concurrent+Request+Limit+on+IIS+8+5+。