【发布时间】：2021-03-17 03:53:35
【问题描述】：
因为我正在与线程饥饿症状作斗争，比如我决定在异步/等待模式下重写整个调用链（I/O、数据库路径）。 在重写 async/await 的巨大努力之后，我非常惊讶的是它对中/高负载没有影响。 所以我决定将测试减少到以下顺序：
WebStressTool -> IIS(反向代理) -> Kestrel(进程外) -> await MiddlewarePipeline.Next() -> async Controller.Action -> await db.StoredProcedure(sql: WAIT FOR 1000ms)
在完整的 async/await 调用链中，每个请求的处理时间应接近 1000 毫秒。 我希望随着请求/秒的增加，响应时间应该保持不变（1000 毫秒）。 结果如下：
- 1-9 rqs/sec -> 响应时间：1010 毫秒。 （WebStresTool：9 rqs/秒）。果然不出所料
- 15 rqs/秒 -> 响应时间：2200 毫秒。 （WebStresTool：9 rqs/秒）。瓶颈
- 25 rqs/秒 - 响应时间：4500 毫秒。 （WebStresTool：9 rqs/秒）。瓶颈 ....等等
随着请求/秒的增加，响应时间呈指数增长。 完全异步/等待场景中的正常行为应该是：随着增加或 rqs/sec 响应时间应该保持不变：时间 = 1000 毫秒（可扩展性）。
因此，这些症状与线程饥饿无关，而是与某处的某些瓶颈问题有关……谁知道呢。
经过更多测试，我发现该问题仅在 IIS（反向代理）下运行时出现。应用程序线程不超过 40 并且具有巨大的负载响应时间。在没有 IIS（只是 kestrel 服务器）的情况下重复测试，结果是成功的。该应用程序是可扩展的。
似乎 IIS 背后的 kestrel 运行是个问题
任何建议、想法、提示等都将受到高度赞赏。
最好的问候
【问题讨论】：
-
新信息：独立运行（不在 IIS 后面作为反向代理）通过了测试。所以问题出在使用 IIS 后面。可能是什么？
标签： multithreading asynchronous kestrel