时间戳

首页 > 解决方案 > Kestrel 限制请求并发

multithreading - Kestrel 限制请求并发

问题描述

因为我正在与线程饥饿症状作斗争，比如我决定在异步/等待模式下重写整个调用链（I/O、数据库路径）。在重写 async/await 的巨大努力之后，我非常惊讶的是它对中/高负载没有影响。所以我决定将测试减少到以下顺序：

WebStressTool -> IIS(反向代理) -> Kestrel(进程外) -> await MiddlewarePipeline.Next() -> async Controller.Action -> await db.StoredProcedure(sql: WAIT FOR 1000ms)

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

  1. 1-9 rqs/sec -> 响应时间：1010 毫秒。（WebStresTool：9 rqs/秒）。它的省长，正如预期的那样
  2. 15 个 rqs/秒 -> 响应时间：2200 毫秒。（WebStresTool：9 rqs/秒）。瓶颈
  3. 25 个 rqs/秒 - 响应时间：4500 毫秒。（WebStresTool：9 rqs/秒）。瓶颈……等等

随着请求/秒的增加，响应时间呈指数增长。完全异步/等待场景中的正常行为应该是：随着增加或 rqs/sec 响应时间应该保持不变：时间 = 1000 毫秒（可扩展性）。

因此，这些症状与线程饥饿无关，而是与某处的某些瓶颈问题有关……谁知道呢。

经过更多测试后，我发现问题仅在 IIS（反向代理）下运行时出现。应用程序线程不超过 40 并且具有巨大的负载响应时间。在没有 IIS（只是 kestrel 服务器）的情况下重复测试，结果是成功的。该应用程序是可扩展的。

似乎 IIS 背后的红隼运行是问题所在

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

此致

标签： multithreadingasynchronouskestrel

解决方案

好吧，我有一个可怕的怀疑：在我的开发机器上运行压力场景受到隐藏的 IIS 自身并发限制的限制。仅在 windows server 上没有限制。这意味着我花了数百个小时来改善响应时间、异步重写热路径、缓存等，而我被这个隐藏的限制误导了。现在我正在移动 windows server 2012 上的压力测试。我很快就会回来

推荐阅读