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

何卫涛

前言：

上次发布了：Taurus.MVC 性能压力测试（ap 压测 和 linux 下wrk 压测）：.NET Core 版本
今天计划准备压测一下 .NET 版本，来测试并记录一下 Taurus.MVC 框架在 .NET 版本的性能，以便后续持续优化改进。
为了方便对比，本文章的电脑环境和测试思路，尽量和上文保持一致，以便方便对比。
下面来看不同场景下的压测结果，以下测试结果会由两台电脑进行分别测试。
一、旧电脑环境：

1. CPU ：Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
2. 内核: 6
3. 逻辑处理器: 6<br>内存：16G

复制代码

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

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

仍然先用ab工具，进行本机压测，试试水。
ab的版本信息不变：

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

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

复制代码

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

1. Server Software:
2. Server Hostname:        192.168.100.100
3. Server Port:            51997
5. Document Path:          /api/hello
6. Document Length:        24 bytes
8. Concurrency Level:      1
9. Time taken for tests:   4.361 seconds
10. Complete requests:      10000
11. Failed requests:        0
12. Write errors:           0
13. Total transferred:      1190000 bytes
14. HTML transferred:       240000 bytes
15. Requests per second:    2293.29 [#/sec] (mean)
16. Time per request:       0.436 [ms] (mean)
17. Time per request:       0.436 [ms] (mean, across all concurrent requests)
18. Transfer rate:          266.51 [Kbytes/sec] received

复制代码

由于是IIS运行，程序里没默认打印时间，这里无法看到单次执行的时候，没法给出一个100万+的美好理论推理值。
B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回）：

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

复制代码

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

1. Document Path:          /api/hello
2. Document Length:        24 bytes
4. Concurrency Level:      8
5. Time taken for tests:   1.593 seconds
6. Complete requests:      10000
7. Failed requests:        0
8. Write errors:           0
9. Total transferred:      1190000 bytes
10. HTML transferred:       240000 bytes
11. Requests per second:    6277.48 [#/sec] (mean)
12. Time per request:       1.274 [ms] (mean)
13. Time per request:       0.159 [ms] (mean, across all concurrent requests)
14. Transfer rate:          729.51 [Kbytes/sec] received
16. Connection Times (ms)
17.               min  mean[+/-sd] median   max
18. Connect:        0    0   0.3      0       1
19. Processing:     0    1   0.4      1       3
20. Waiting:        0    1   0.4      1       3
21. Total:          1    1   0.4      1       4
23. Percentage of the requests served within a certain time (ms)
24.   50%      1
25.   66%      1
26.   75%      1
27.   80%      2
28.   90%      2
29.   95%      2
30.   98%      2
31.   99%      2
32. 100%      4 (longest request)

复制代码

ab 在.NET8 中只能在2个并发中测试出5765的成绩，而在.NET4 中能在8个并发中测试出6277的成绩。
我怀疑是不是我调整了程序引发的，于是重新对.NET8进行测试：
测试结果显示，数据一样，这~~~~
C、使用 CYQ.Data 读数据库，输出 Json，来看看压测结果（读数据库接口）

测试代码：

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

复制代码

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

下面直接进行压测

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

复制代码

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

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

复制代码

目前看来，在ab的测试结果中，倒是 .NET 程序在 Windows 部署中更优。
下面用 wrk 进行极限压测再看看结果：
2、测试 Window 11 下，虚拟机wrk工具压测：（读数据库输出Json）

虚拟机环境：

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

复制代码

分完虚拟机后，本机就剩下 4 核了，再去掉打开任务管理器，就占掉了10%的cpu，当个3核用了。
不过问题不大，尽管测就是了，为了保持接口的通用性，继续使用读数据库输出 Json 的接口：
先使用1线程1个链接测试试试水：

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

复制代码

压测发现一点反应都木有，直接卡死没反应，经过反复排查，发现是端口问题，不知为何，对该端口就是无法发起请求，链接超时。
更新 80 端口，重新测试，测试结果：qps = 1084  【对比：.NET Core 8 对应的 qps = 1518】

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

复制代码

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

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

复制代码

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

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

复制代码

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

小结：

1. .NET 8 （qps = 23303，CPU 31%，Host = Kestrel ）
3. .NET 4  （qps =14171，CPU 45%，host = IIS ）

复制代码

可以看出，在极限压测试之下，.NET Core 比 .NET 的确是更少的资源，能同时处理更多的并发数。
下面，我们换到新电脑上走走看，看新电脑有啥新突破没有。
二、新电脑环境：

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

复制代码

接下来，我们看看新电脑的表现如何，使用一样的程序部署：Taurus.MVC + IIS + 本地 MSSQL2012。
A、先测试单线程的运行性能（简单接口返回）：

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

复制代码

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

1. Document Path:          /api/hello
2. Document Length:        24 bytes
4. Concurrency Level:      1
5. Time taken for tests:   22.728 seconds
6. Complete requests:      100000
7. Failed requests:        0
8. Write errors:           0
9. Total transferred:      11900000 bytes
10. HTML transferred:       2400000 bytes
11. Requests per second:    4399.90 [#/sec] (mean)
12. Time per request:       0.227 [ms] (mean)
13. Time per request:       0.227 [ms] (mean, across all concurrent requests)
14. Transfer rate:          511.32 [Kbytes/sec] received

复制代码

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

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

复制代码

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

1. Document Path:          /api/hello
2. Document Length:        24 bytes
4. Concurrency Level:      48
5. Time taken for tests:   5.253 seconds
6. Complete requests:      100000
7. Failed requests:        0
8. Write errors:           0
9. Total transferred:      11900000 bytes
10. HTML transferred:       2400000 bytes
11. Requests per second:    19037.81 [#/sec] (mean)
12. Time per request:       2.521 [ms] (mean)
13. Time per request:       0.053 [ms] (mean, across all concurrent requests)
14. Transfer rate:          2212.40 [Kbytes/sec] received

复制代码

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

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

复制代码

接下来，又到使用 wrk 使用压限压测试看看结果，没错，同样测的是 wrk 的极限，不是程序的。
2、测试 Window 11 下，虚拟机wrk工具压测：（简单接口）

虚拟机环境：

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

复制代码

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

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

复制代码

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

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

复制代码

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

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

复制代码

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

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

复制代码

压测试过程，观察两个cpu，虚拟机（110%-130%，2核还没跑满），程序跑了30%左右，整体40-50%左右，感觉还能往上跑。
估计是压力不够，试着分给虚拟机多2核，看看有没有效果。
虚拟机环境：

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

复制代码

继续压测试：

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

复制代码

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

1. Running 1m test @ http://192.168.100.102/api/hello
2.   128 threads and 2048 connections
3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
4.     Latency    53.05ms   64.23ms 891.51ms   87.32%
5.     Req/Sec   374.01     87.90     2.23k    73.18%
6.   2861819 requests in 1.00m, 763.30MB read
7.   Non-2xx or 3xx responses: 1245021
8. Requests/sec:  47617.29
9. 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 本机）：

接口的调用输出：

进行压测：

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

复制代码

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

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

复制代码

CPU 结果和上一个差不多，该压测结果也有近50%的非正常值，稳定的测试结果，估计得降10%-20%。
为了总结比较，追加将 .NET8 程序部署在IIS，并进行压力测试：

.NET 部署 IIS 的简单步骤：.NET Core 8 部署在 IIS 的简单三步
下面进行压测试：

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

复制代码

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

1. Running 15s test @ http://192.168.100.102:8011/api/hello
2.   128 threads and 2000 connections
3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
4.     Latency    83.21ms  104.38ms   1.60s    83.56%
5.     Req/Sec   316.97    235.61     1.95k    70.51%
6.   579569 requests in 15.11s, 118.46MB read
7.   Non-2xx or 3xx responses: 8274
8. Requests/sec:  38356.07
9. 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 运行程序

 

来源:https://www.cnblogs.com/cyq1162/p/18135830
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！