ASP.NET Core WebAPI在Azure App Service负载测试中简单请求表现极差

老哥，这问题确实有点反常识——明明接口啥逻辑都没做直接返回OK，到20req/s就突然雪崩，我帮你捋几个大概率的排查方向，都是我碰到过或者圈内常遇到的坑：

1. 先排查负载测试发起端（Azure DevOps代理）的瓶颈 #

别光顾着看App Service，测试代理本身可能先顶不住了：

• 监控代理机器的CPU、内存、网络带宽：20req/s看起来不高，但如果代理是Azure DevOps默认的低配虚拟机（比如Standard_DS2_v2以下），JMeter/Taurus生成请求时可能已经把代理资源吃满，导致请求排队发不出去，最终体现为App Service的响应时间暴涨。
• 检查Taurus的执行配置：有没有不小心设置了不合理的速率限制或者线程参数？比如下面这种配置如果throughput设错了可能导致异常：

  execution:
    - concurrency: 20
      ramp-up: 1m
      hold-for: 5m
      throughput: 20  # 这里如果和并发不匹配，可能导致请求排队
      scenario: default
  

  另外，Taurus默认的JMeter配置有没有启用多余的监听器？比如view_results_tree这类重监听器会严重拖慢测试进程，高并发测试一定要关掉。

2. ASP.NET Core应用的隐藏“暗箱”操作 #

哪怕接口第一行就return OK，请求管道里的其他环节可能在搞事情：

• 中间件排查：把非必要的中间件（比如认证、日志、CORS、健康检查之外的）临时注释掉，逐步测试看响应时间是否恢复。我之前碰到过某个日志中间件在高并发下同步写文件，直接把线程池堵死的情况。
• 线程池配置验证：确认ThreadPool.SetMinThreads是不是在程序启动的最早期（比如Program.cs的第一行）设置的，而且数值足够（比如根据实例CPU核心数设置，比如8核就设minWorkerThreads=32，minIOCPThreads=32）。另外，检查Azure App Service的ARR亲和性是不是开着——如果开了，请求会被粘到同一个实例，哪怕你加了多实例也没用，单实例先过载导致响应时间暴涨。
• App Service的运行时配置：有没有设置WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT？这个参数控制自动扩缩容的最大实例数，要是设得太低，高并发下没法扩容。另外，看看App Service的“诊断和解决问题”里的“性能检测器”，有没有看到线程池排队、CPU突增的情况。

3. 网络层面的隐形限制 #

Azure的网络规则很容易被忽略：

• 区域延迟：如果Azure DevOps代理和App Service不在同一个区域，跨区域的网络延迟在高并发下会被放大，甚至触发Azure的网络限流。先把代理和App Service放到同一个区域测试，排除跨区问题。
• NSG/防火墙限流：检查App Service的入站NSG规则，有没有设置速率限制（比如每秒允许的请求数）？或者Azure防火墙是不是对该App Service设置了请求阈值？超过阈值后会被限流，导致响应时间骤增。

4. JMeter的底层配置细节 #

JMeter的一些默认配置可能不适合高并发：

• HTTP连接池设置：JMeter默认的HTTP连接池大小可能不够，导致每次请求都要新建连接，开销极大。可以在HTTP请求默认值里设置Max Connections per Host为合理数值（比如100），Connection Timeout设短一点（比如3000ms）。
• 采样超时设置：如果JMeter的采样超时设得太长（比如20秒），刚好和你看到的响应时间匹配，可能是请求在代理端排队，而不是App Service真的用了20秒处理。可以把超时设短，看是不是会出现大量超时错误，以此判断是代理端还是服务端的问题。

内容的提问来源于stack exchange，提问作者joacho