K6压测显示ASP.NET Core Web API性能远逊于Minimal API，求分析

测试环境与配置 #

• 测试工具：K6
• 测试目标：
  • 默认ASP.NET Core Web API的WeatherForecast接口
  • 默认ASP.NET Core Minimal API的WeatherForecast接口
• K6测试代码：

import http from 'k6/http';
import { check } from 'k6';

export let options = {
    vus: 50,
    iterations: 10000
}

export default () => {
     const url = 'https://localhost:7281/weatherforecast';
     const res = http.get(url);

    check(res, { 'Success!': (r) => r.status == 200 });
};

测试结果 #

ASP.NET Core Web API 测试数据 #

scenarios: (100.00%) 1 scenario, 50 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 10000 iterations shared among 50 VUs (maxDuration: 10m0s, gracefulStop: 30s)


     ✓ Success!

     checks.........................: 100.00% ✓ 10000      ✗ 0
     data_received..................: 4.6 MB  48 kB/s
     data_sent......................: 498 kB  5.2 kB/s
     http_req_blocked...............: avg=1.14ms   min=0s       med=0s       max=342.53ms p(90)=0s       p(95)=0s
     http_req_connecting............: avg=6.6µs    min=0s       med=0s       max=3ms      p(90)=0s       p(95)=0s
       { expected_response:true }...: avg=478.97ms min=113.42ms med=467.31ms max=905.99ms p(90)=584.76ms p(95)=636.13ms
     http_req_failed................: 0.00%   ✓ 0          ✗ 10000
     http_req_receiving.............: avg=154.77µs min=0s       med=0s       max=89.79ms  p(90)=629.73µs p(95)=846.5µs
     http_req_sending...............: avg=24.48µs  min=0s       med=0s       max=1.37ms   p(90)=0s       p(95)=0s
     http_req_tls_handshaking.......: avg=1.1ms    min=0s       med=0s       max=333.45ms p(90)=0s       p(95)=0s
     http_req_waiting...............: avg=478.79ms min=112.21ms med=467.16ms max=905.99ms p(90)=584.76ms p(95)=635.67ms
     http_reqs......................: 10000   104.010128/s
     iteration_duration.............: avg=480.15ms min=189.12ms med=467.43ms max=952.73ms p(90)=586.82ms p(95)=639.5ms
     iterations.....................: 10000   104.010128/s
     vus............................: 32      min=32       max=50
     vus_max........................: 50      min=50       max=50


running (01m36.1s), 00/50 VUs, 10000 complete and 0 interrupted iterations
default ✓ [======================================] 50 VUs  01m36.1s/10m0s  10000/10000

ASP.NET Core Minimal API 测试数据 #

scenarios: (100.00%) 1 scenario, 50 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 10000 iterations shared among 50 VUs (maxDuration: 10m0s, gracefulStop: 30s)


     ✓ Success!

     checks.........................: 100.00% ✓ 10000       ✗ 0
     data_received..................: 4.5 MB  2.2 MB/s
     data_sent......................: 498 kB  252 kB/s
     http_req_blocked...............: avg=495.97µs min=0s     med=0s     max=126.87ms p(90)=0s       p(95)=0s
     http_req_connecting............: avg=6.7µs    min=0s     med=0s     max=2.99ms   p(90)=0s       p(95)=0s
     http_req_duration..............: avg=9.33ms   min=2.95ms med=8.68ms max=37.69ms  p(90)=10.54ms  p(95)=10.9ms
       { expected_response:true }...: avg=9.33ms   min=2.95ms med=8.68ms max=37.69ms  p(90)=10.54ms  p(95)=10.9ms
     http_req_failed................: 0.00%   ✓ 0           ✗ 10000
     http_req_receiving.............: avg=62.85µs  min=0s     med=0s     max=1.02ms   p(90)=257.76µs p(95)=512.6µs
     http_req_sending...............: avg=27.64µs  min=0s     med=0s     max=1.51ms   p(90)=0s       p(95)=253.58µs
     http_req_tls_handshaking.......: avg=456.24µs min=0s     med=0s     max=118.87ms p(90)=0s       p(95)=0s
     http_req_waiting...............: avg=9.24ms   min=2.95ms med=8.59ms max=37.69ms  p(90)=10.44ms  p(95)=10.82ms
     http_reqs......................: 10000   5048.479794/s
     iteration_duration.............: avg=9.88ms   min=2.95ms med=8.73ms max=138.38ms p(90)=10.61ms  p(95)=10.99ms
     iterations.....................: 10000   5048.479794/s
     vus............................: 50      min=50        max=50
     vus_max........................: 50      min=50        max=50


running (00m02.0s), 00/50 VUs, 10000 complete and 0 interrupted iterations
default ✓ [======================================] 50 VUs  00m02.0s/10m0s  10000/10000 shared iters

性能差异核心原因分析 #

从测试数据看，Minimal API的请求处理效率是传统Web API的几十倍，核心差异来自两者的架构设计和请求处理流程：

1. 请求管道轻量化
   传统Web API基于控制器架构，请求必须经过控制器激活、模型绑定验证、过滤器管道（授权、动作过滤器等）等一系列流程，即使是默认的WeatherForecast接口，这些基础生命周期步骤也会触发，带来额外开销。
   Minimal API采用直接映射端点到委托的方式，跳过了控制器激活、过滤器管道等非必要步骤，请求处理路径更短更直接。

2. 反射与类型激活开销
   传统Web API处理请求时，需要通过反射查找控制器类型、激活实例、调用动作方法，这类反射操作在高并发场景下会积累显著性能损耗。
   Minimal API在启动阶段就完成了端点委托的编译绑定，运行时无需反射查找，直接执行目标方法，大幅减少了运行时计算开销。

3. 默认中间件栈差异
   默认创建的Web API项目包含更多默认中间件（如Swagger、控制器路由中间件等），即使未直接使用，这些中间件仍会存在于请求管道中，增加了请求处理步骤；而Minimal API默认的中间件栈更精简，进一步降低了处理成本。

4. 并发资源利用效率
   从vus指标可见，Web API的并发用户数最高仅用到32，而Minimal API始终保持50满负载，说明Web API在高并发下出现了线程池阻塞或资源竞争，而Minimal API的轻量化设计能更高效地利用服务器资源，处理更多并发请求。

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