问限制请求并发性

EN

因为我正在与线程饥饿的症状作斗争，比如我决定在异步/等待模式中重写整个调用链(I/O，db路径)。在重写异步/等待的巨大努力之后，我感到非常惊讶的是，这对中/高负载没有影响。因此，我决定将测试简化为以下顺序：

WebStressTool -> IIS(反向代理) -> Kestrel(进程外) ->等待MiddlewarePipeline.Next() ->异步Controller.Action ->等待db.StoredProcedure(sql:等待1000 IIS)

每个请求的处理时间应该在接近1000 in的全异步/等待调用链中。我希望随着请求/秒的增加，响应时间应该保持不变(1000 as )。结果如下：

1. 1-9 rqs/秒-> ResponseTime: 1010 rqs。(WebStresTool: 9 rqs/秒)
2. 15 rqs/sec -> ResponseTime: 2200 as。(WebStresTool: 9 rqs/秒)瓶颈
3. 25 rqs/秒- ResponseTime: 4500 rqs。(WebStresTool: 9 rqs/秒)瓶颈....and (瓶颈

)

随着请求/sec的增加，响应时间呈指数增长。在完全异步/等待场景中，通常的行为应该是:随着rqs/秒的增加，响应时间应该保持不变: time =1000 as (可伸缩性)。

所以症状与线程饥饿无关，而与某些瓶颈问题有关.谁知道呢。

经过更多的测试后，我发现只有在IIS (反向代理)下运行时才会出现问题。应用程序线程不超过40，负载响应时间很长。在没有IIS的情况下重复测试(只有kestrel服务器)，结果是成功的。应用程序是可伸缩的。

似乎问题在于IIS背后的kestrel运行。

如有任何建议、想法、提示等，将不胜感激。

诚挚的问候