Taurus.MVC 性能压力测试（ap 压测和 linux 下wrk 压测）：.NET 版本

前言：

上次发布了：Taurus.MVC 性能压力测试（ap 压测和 linux 下wrk 压测）：.NET Core 版本

今天计划准备压测一下 .NET 版本，来测试并记录一下 Taurus.MVC 框架在 .NET 版本的性能，以便后续持续优化改进。

为了方便对比，本文章的电脑环境和测试思路，尽量和上文保持一致，以便方便对比。

下面来看不同场景下的压测结果，以下测试结果会由两台电脑进行分别测试。

一、旧电脑环境：

CPU ：Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
内核: 6
逻辑处理器: 6
内存：16G

程序在 .NET4 编绎，以 Windows 11 为主机直接运行在 IIS 环境：

1、测试 Window 11 下，单机ab工具压测：

仍然先用ab工具，进行本机压测，试试水。

ab的版本信息不变：

A、先测试单线程的运行性能（简单接口返回）：

ab -n 100000 -c 1 http://192.168.100.102:51996/api/hello

测试结果：并发数1，qps = 2293 【对比：.NET Core 8 对应的 qps = 3595】

Server Software:
Server Hostname:        192.168.100.100
Server Port:            51997

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      1
Time taken for tests:   4.361 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1190000 bytes
HTML transferred:       240000 bytes
Requests per second:    2293.29 [#/sec] (mean)
Time per request:       0.436 [ms] (mean)
Time per request:       0.436 [ms] (mean, across all concurrent requests)
Transfer rate:          266.51 [Kbytes/sec] received

由于是IIS运行，程序里没默认打印时间，这里无法看到单次执行的时候，没法给出一个100万+的美好理论推理值。

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

ab -n 100000 -c 4 http://192.168.100.102:51996/api/hello

测试结果：qps = 6277 【对比：.NET Core 8 对应的 qps = 5765】

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      8
Time taken for tests:   1.593 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1190000 bytes
HTML transferred:       240000 bytes
Requests per second:    6277.48 [#/sec] (mean)
Time per request:       1.274 [ms] (mean)
Time per request:       0.159 [ms] (mean, across all concurrent requests)
Transfer rate:          729.51 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       1
Processing:     0    1   0.4      1       3
Waiting:        0    1   0.4      1       3
Total:          1    1   0.4      1       4

Percentage of the requests served within a certain time (ms)
  50%      1
  66%      1
  75%      1
  80%      2
  90%      2
  95%      2
  98%      2
  99%      2
 100%      4 (longest request)

ab 在.NET8 中只能在2个并发中测试出5765的成绩，而在.NET4 中能在8个并发中测试出6277的成绩。

我怀疑是不是我调整了程序引发的，于是重新对.NET8进行测试：

测试结果显示，数据一样，这~~~~

C、使用 CYQ.Data 读数据库，输出 Json，来看看压测结果（读数据库接口）

测试代码：

public void HelloDb(string msg)
{
    string conn = "server=.;database=MSLog;uid=sa;pwd=123456";
    using (MProc proc = new MProc("select top 1 * from SysLogs", conn))
    {
        Write(proc.ExeJson());
    }
}

运行结果：返回一条数据：

下面直接进行压测

ab -n 10000 -c 8 http://192.168.100.100:51997/api/hellodb

压测结果：并发数 8 ，qps = 6031 【对比：.NET Core 8 对应的 qps = 5470】

Concurrency Level:      8
Time taken for tests:   1.658 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      10550000 bytes
HTML transferred:       9590000 bytes
Requests per second:    6031.36 [#/sec] (mean)
Time per request:       1.326 [ms] (mean)
Time per request:       0.166 [ms] (mean, across all concurrent requests)
Transfer rate:          6213.95 [Kbytes/sec] received

目前看来，在ab的测试结果中，倒是 .NET 程序在 Windows 部署中更优。

下面用 wrk 进行极限压测再看看结果：

2、测试 Window 11 下，虚拟机wrk工具压测：（读数据库输出Json）

虚拟机环境：

CPU ：Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
内核: 2
逻辑处理器: 2
内存：4G

分完虚拟机后，本机就剩下 4 核了，再去掉打开任务管理器，就占掉了10%的cpu，当个3核用了。

不过问题不大，尽管测就是了，为了保持接口的通用性，继续使用读数据库输出 Json 的接口：

先使用1线程1个链接测试试试水：

 wrk -t 1 -c1 -d 10s http://192.168.100.100:51997/api/hellodb

压测发现一点反应都木有，直接卡死没反应，经过反复排查，发现是端口问题，不知为何，对该端口就是无法发起请求，链接超时。

更新 80 端口，重新测试，测试结果：qps = 1084 【对比：.NET Core 8 对应的 qps = 1518】

Running 10s test @ http://192.168.100.100/api/hellodb
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.89ms   12.02ms 136.48ms   93.00%
    Req/Sec     1.11k   319.04     1.45k    81.44%
  10915 requests in 10.06s, 10.78MB read
Requests/sec:   1084.60
Transfer/sec:      1.07MB

不断调整参数，来看看它的极限值：

wrk -t 2 -c 1024 -d 10 http://192.168.100.100/api/hellodb

测试结果：qps = 14171 【对比：.NET Core 8 对应的 qps = 23303】

Running 10s test @ http://192.168.100.100/api/hellodb
  2 threads and 1024 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    71.11ms   55.89ms 643.51ms   92.75%
    Req/Sec     7.57k     2.96k   15.56k    74.43%
  142731 requests in 10.07s, 140.86MB read
  Socket errors: connect 5, read 0, write 0, timeout 0
  Non-2xx or 3xx responses: 325
Requests/sec:  14171.14
Transfer/sec:     13.99MB

观察测试 CPU 结果，程序占45%，数据库和虚拟机占一半。

小结：

.NET 8 （qps = 23303，CPU 31%，Host = Kestrel ）

.NET 4  （qps =14171，CPU 45%，host = IIS ）

可以看出，在极限压测试之下，.NET Core 比 .NET 的确是更少的资源，能同时处理更多的并发数。

下面，我们换到新电脑上走走看，看新电脑有啥新突破没有。

二、新电脑环境：

CPU    13th Gen Intel(R) Core(TM) i5-13600KF
内核:    14
逻辑处理器: 20
内存：64G

接下来，我们看看新电脑的表现如何，使用一样的程序部署：Taurus.MVC + IIS + 本地 MSSQL2012。

A、先测试单线程的运行性能（简单接口返回）：

ab -n 100000 -c 1 http://192.168.100.102/api/hello

测试结果：并发数1，qps = 4399 【对比：.NET Core 8 对应的 qps = 11389】

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      1
Time taken for tests:   22.728 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11900000 bytes
HTML transferred:       2400000 bytes
Requests per second:    4399.90 [#/sec] (mean)
Time per request:       0.227 [ms] (mean)
Time per request:       0.227 [ms] (mean, across all concurrent requests)
Transfer rate:          511.32 [Kbytes/sec] received

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

ab -n 100000 -c 48 http://192.168.100.102/api/hello

测试结果：并发数48，qps = 19037【对比：.NET Core 8 对应的 qps = 18247】

Document Path:          /api/hello
Document Length:        24 bytes

Concurrency Level:      48
Time taken for tests:   5.253 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11900000 bytes
HTML transferred:       2400000 bytes
Requests per second:    19037.81 [#/sec] (mean)
Time per request:       2.521 [ms] (mean)
Time per request:       0.053 [ms] (mean, across all concurrent requests)
Transfer rate:          2212.40 [Kbytes/sec] received

同样 ab 压不出结果，程序的cpu才跑了不到2%，倒是ab自身，占了快40%的cpu。

小结：

在新旧电脑测试中，ab 的最大压测值（旧电脑：6277，新电脑：19037），同样体现出是3倍左右的性能差异。

接下来，又到使用 wrk 使用压限压测试看看结果，没错，同样测的是 wrk 的极限，不是程序的。

2、测试 Window 11 下，虚拟机wrk工具压测：（简单接口）

虚拟机环境：

CPU    13th Gen Intel(R) Core(TM) i5-13600KF
内核:    2
逻辑处理器: 2
内存：4G

先给虚拟机2核，本机剩下 12 核了，可以好好压一下了。

wrk -t 1 -c 1 -d 10s http://192.168.100.102/api/hello

测试结果：1并发，qps = 4090【对比：.NET Core 8 对应的 qps = 14084】

Running 10s test @ http://192.168.100.102/api/hello
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   271.44us  530.73us  16.09ms   99.50%
    Req/Sec     4.11k   564.42     8.67k    93.00%
  40950 requests in 10.01s, 3.91MB read
Requests/sec:   4090.60
Transfer/sec:    399.47KB

和 ab 一样，一个链接并发压不出什么效果，加大效果看看。

wrk -t 32 -c 2048 -d 10s http://192.168.100.102/api/hello

测试结果：qps = 36194 【对比：.NET Core 8 对应的 qps = 84306】

Running 10s test @ http://192.168.100.102/api/hello
  32 threads and 2048 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    26.14ms   12.61ms 114.24ms   73.00%
    Req/Sec     2.30k   558.55     6.57k    71.40%
  365826 requests in 10.11s, 34.89MB read
  Socket errors: connect 1059, read 0, write 0, timeout 0
Requests/sec:  36194.23
Transfer/sec:      3.45MB

压测试过程，观察两个cpu，虚拟机（110%-130%，2核还没跑满），程序跑了30%左右，整体40-50%左右，感觉还能往上跑。

估计是压力不够，试着分给虚拟机多2核，看看有没有效果。

虚拟机环境：

CPU    13th Gen Intel(R) Core(TM) i5-13600KF
内核:    4
逻辑处理器: 4
内存：6G

继续压测试：

wrk -t 128 -c 2048 -d 60s http://192.168.100.102/api/hello

测试结果：qps = 47617【对比：.NET Core 8 对应的 qps = 105462】

Running 1m test @ http://192.168.100.102/api/hello
  128 threads and 2048 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    53.05ms   64.23ms 891.51ms   87.32%
    Req/Sec   374.01     87.90     2.23k    73.18%
  2861819 requests in 1.00m, 763.30MB read
  Non-2xx or 3xx responses: 1245021
Requests/sec:  47617.29
Transfer/sec:     12.70MB

压测试过程，观察两个cpu，虚拟机（200%-230%左右，跑满2核多一点），程序跑了35%-40%左右，整体60-65%左右。

由于走完下面的测试流程，重新回到此处，观察测试结果有近50%的非正常状态码，所以重新压测，降低参数，重新测试：

经过反复压测，找不回之前的结果了，我了和去，wrk 的参数，看来都是在随机状态下的随机结果。

重复压的结果，是 wrk 上不去，cpu 也跑不上去，程序 cpu 也同样跑不上去了，只好暂时采用这个值了，稳定的测试结果，个人觉得应该降10%-20%再取值。

重新压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012 安装在Window 11 本机）：

接口的调用输出：

进行压测：

wrk -t128 -c 4096-d 60s http://192.168.100.102/api/hellodb

测试结果：qps = 45582【对比：.NET Core 8 对应的 qps = 73122】

Running 1m test @ http://192.168.100.102/api/hellodb
  128 threads and 4096 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    86.07ms  109.54ms   1.99s    84.76%
    Req/Sec   357.79    106.70     2.61k    71.47%
  2739712 requests in 1.00m, 2.01GB read
  Socket errors: connect 0, read 0, write 0, timeout 66
  Non-2xx or 3xx responses: 1309827
Requests/sec:  45582.33
Transfer/sec:     34.17MB

CPU 结果和上一个差不多，该压测结果也有近50%的非正常值，稳定的测试结果，估计得降10%-20%。

为了总结比较，追加将 .NET8 程序部署在IIS，并进行压力测试：

.NET 部署 IIS 的简单步骤：.NET Core 8 部署在 IIS 的简单三步

下面进行压测试：

wrk -t128 -c 2000 -d 30s http://192.168.100.102:8011/api/hello

测试结果：qps = 38356【对比：.NET Core 8 Kestrel 对应的 qps = 105462】

Running 15s test @ http://192.168.100.102:8011/api/hello
  128 threads and 2000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    83.21ms  104.38ms   1.60s    83.56%
    Req/Sec   316.97    235.61     1.95k    70.51%
  579569 requests in 15.11s, 118.46MB read
  Non-2xx or 3xx responses: 8274
Requests/sec:  38356.07
Transfer/sec:      7.84MB

压测试过程，观察两个cpu，虚拟机（150%-190%左右，2核都跑不满），程序才跑了15%-20%左右，估计还有很大上升空间。

不过测试就这了，主要是整体观察，有个大体印象，毕竟抛开业务追求更高的数字意义不咋么大。

总结：

ab 压测极限：

.NET8【旧电脑：5765（Kestrel），新电脑：18247（Kestrel）】

.NET4【旧电脑：6277（IIS），新电脑：19037（IIS）】

wrk 压测极限：

.NET8【旧电脑：23303（Kestrel），新电脑：105462（Kestrel）、38356（Kestrel + IIS 反向代理）】

.NET4【旧电脑：14171（IIS），新电脑：47617（IIS 非稳定结果）、36194（IIS 稳定结果）】

从以上的数据对比，可以看出，整体上，.NET Core 使用 Kestrel 时的性能无论是跑在 Window 上，还是跑在 Linux 上，性能都会比.NET 优秀很多。

如果.NET Core 程序部署在IIS中，经过IIS的反向代理递减性能后，性能则和 .NET 差不多。

由于系统环境的影响，测试结果和参数，都是时刻在一定的范围内变化的，因此，测试结果只能当作参考。

附本文的运行程序：Taurus.MVC .NET4 运行程序

posted on 2024-04-16 10:52 路过秋天阅读(374) 评论(0) 编辑收藏举报

刷新页面返回顶部

坚持 .NET 三十年，持续提供、更新、创造系列框架，包括ORM、MVC、微服务、分布式等框架，愿国产框架百花齐放，提升国内.NET行业整体竞争力。

-- 理想很美好，现实很残酷，坚持在路上，只因初心仍存

Taurus.MVC 性能压力测试（ap 压测和 linux 下wrk 压测）：.NET 版本

前言：

一、旧电脑环境：

1、测试 Window 11 下，单机ab工具压测：

A、先测试单线程的运行性能（简单接口返回）：

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

C、使用 CYQ.Data 读数据库，输出 Json，来看看压测结果（读数据库接口）

2、测试 Window 11 下，虚拟机wrk工具压测：（读数据库输出Json）

小结：

二、新电脑环境：

A、先测试单线程的运行性能（简单接口返回）：

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

2、测试 Window 11 下，虚拟机wrk工具压测：（简单接口）

重新压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012 安装在Window 11 本机）：

为了总结比较，追加将 .NET8 程序部署在IIS，并进行压力测试：

总结：

ab 压测极限：

wrk 压测极限：

公告

坚持 .NET 三十年，持续提供、更新、创造系列框架，包括ORM、MVC、微服务、分布式等框架，愿国产框架百花齐放，提升国内.NET行业整体竞争力。 -- 理想很美好，现实很残酷，坚持在路上，只因初心仍存

Taurus.MVC 性能压力测试（ap 压测 和 linux 下wrk 压测）：.NET 版本

前言：

一、旧电脑环境：

1、测试 Window 11 下，单机ab工具压测：

A、先测试单线程的运行性能（简单接口返回）：

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

C、使用 CYQ.Data 读数据库，输出 Json，来看看压测结果（读数据库接口）

2、测试 Window 11 下，虚拟机wrk工具压测：（读数据库输出Json）

小结：

二、新电脑环境：

A、先测试单线程的运行性能（简单接口返回）：

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

2、测试 Window 11 下，虚拟机wrk工具压测：（简单接口）

重新压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012 安装在Window 11 本机）：

为了总结比较，追加将 .NET8 程序部署在IIS，并进行压力测试：

总结：

ab 压测极限：

wrk 压测极限：

公告

坚持 .NET 三十年，持续提供、更新、创造系列框架，包括ORM、MVC、微服务、分布式等框架，愿国产框架百花齐放，提升国内.NET行业整体竞争力。

-- 理想很美好，现实很残酷，坚持在路上，只因初心仍存

Taurus.MVC 性能压力测试（ap 压测和 linux 下wrk 压测）：.NET 版本