asp.net - ASP.NET处理程序，手动线程和COM服务器

Question

我正在使用一个遗留应用程序，其中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上下文已传递到池线程

运行.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+。