翼度科技»论坛 编程开发 .net 查看内容

Taurus.MVC 性能压力测试(ap 压测 和 linux 下wrk 压测):.NET Core 版本

5

主题

5

帖子

15

积分

新手上路

Rank: 1

积分
15
前言:

最近的 Taurus.MVC 版本,对性能这一块有了不少优化,因此准备进行一下压测,来测试并记录一下 Taurus.MVC 框架的性能,以便后续持续优化改进。
今天先压测 .NET Core 版本,后续有时间再压测一下.NET 版本。
下面来看不同场景下的压测结果,以下测试结果会由两台电脑进行分别测试。
一、旧电脑环境:
  1. CPU :Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
  2. 内核: 6
  3. 逻辑处理器: 6<br>内存:16G
复制代码
程序在 .NET8 编绎,以 Kestrel 为主机直接运行在 Window 环境:

1、测试 Window 11 下,单机ab工具压测:

由于ab工具占用资源不多,发起的并发能力也有限,先用它进行本机压测,试试水。
ab的版本信息:

A、先测试单线程的运行性能(简单接口返回,控制台带日志输出):
  1. ab -n 100000 -c 1 http://192.168.100.102:51996/api/hello
复制代码
测试结果:并发数1,qps =  3263
  1. Server Software:
  2. Server Hostname:        192.168.100.102
  3. Server Port:            51996
  4. Document Path:          /api/hello
  5. Document Length:        24 bytes
  6. Concurrency Level:      1
  7. Time taken for tests:   30.641 seconds
  8. Complete requests:      100000
  9. Failed requests:        0
  10. Write errors:           0
  11. Total transferred:      13900000 bytes
  12. HTML transferred:       2400000 bytes
  13. Requests per second:    3263.63 [#/sec] (mean)
  14. Time per request:       0.306 [ms] (mean)
  15. Time per request:       0.306 [ms] (mean, across all concurrent requests)
  16. Transfer rate:          443.01 [Kbytes/sec] received
复制代码
看一下程序运行的时间:

从程序打印的日志上看,接口执行时间仅有0.03毫秒,理论值单线程压测是可以达到1000/0.0345= 28089,
去掉控制器日志输出,还能再提升1下,再配置个64核cpu,就是传说中的轻轻松松的单机百万qps了。
B、我们调整一下参数,看看ab在单机下能压出多少来(简单接口返回,控制台带日志输出):
  1. ab -n 100000 -c 2 http://192.168.100.102:51996/api/hello
复制代码
测试结果:
  1. Concurrency Level:      2
  2. Time taken for tests:   18.187 seconds
  3. Complete requests:      100000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      13900000 bytes
  7. HTML transferred:       2400000 bytes
  8. Requests per second:    5498.28 [#/sec] (mean)
  9. Time per request:       0.364 [ms] (mean)
  10. Time per request:       0.182 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          746.35 [Kbytes/sec] received
复制代码
没办法,只能压 2 个并发链接,CPU 跑满了,程序占40%多,ab也占了40%多,说好的ab不吃资源的,直接cpu拉走一半,呵呵。
C、我们关闭日志输出,重新看看上面的两个能测试出多少(简单接口返回,控制台无日志输出):

我们添加以下代码,关闭 Kestrel 默认的控制台信息输出:
  1. services.AddLogging(op => op.SetMinimumLevel(LogLevel.None));
复制代码
【后续的测试,都保持控制器日志关闭】
重新编绎后,进行重新测试:
测试结果:并发数1,qps = 3595
  1. Concurrency Level:      1
  2. Time taken for tests:   2.781 seconds
  3. Complete requests:      10000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      1390000 bytes
  7. HTML transferred:       240000 bytes
  8. Requests per second:    3595.51 [#/sec] (mean)
  9. Time per request:       0.278 [ms] (mean)
  10. Time per request:       0.278 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          488.06 [Kbytes/sec] received
复制代码
关闭日志,提升了300多,后续测试,将会保持控制台日志的关闭。
测试结果:并发数 2,qps = 5765
  1. Concurrency Level:      2
  2. Time taken for tests:   1.734 seconds
  3. Complete requests:      10000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      1390000 bytes
  7. HTML transferred:       240000 bytes
  8. Requests per second:    5765.77 [#/sec] (mean)
  9. Time per request:       0.347 [ms] (mean)
  10. Time per request:       0.173 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          782.66 [Kbytes/sec] received
复制代码
接下来,我们将接口调整一下,单纯的返回 Hello World 没啥看头,改成常规一些。
D、使用 CYQ.Data 读数据库,输出 Json,来看看压测结果(读数据库接口,控制台无日志输出)

测试代码:
  1. public void Hello(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. }
复制代码
运行结果:返回一条数据:

下面直接进行压测结果:并发数 2 ,qps = 5470,和未关闭日志输出时差不多。
  1. Concurrency Level:      2
  2. Time taken for tests:   1.828 seconds
  3. Complete requests:      10000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      10810000 bytes
  7. HTML transferred:       9590000 bytes
  8. Requests per second:    5470.23 [#/sec] (mean)
  9. Time per request:       0.366 [ms] (mean)
  10. Time per request:       0.183 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          5774.73 [Kbytes/sec] received
复制代码
小结:
  1. 从上面的测试结果,观察CPU中可以看出,ab 这个工具,吃 cpu 资源不说,其并发数量也有限。
复制代码
下面更换 wrk 进行测试,由于 wrk 只能在 linux 中运行,因此在本机上,开启了虚拟机。
2、测试 Window 11 下,虚拟机wrk工具压测:(读数据库输出,控制台无日志输出)

虚拟机环境:
  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.102:51996/api/hello
复制代码
测试结果:qps = 1518
  1. Running 10s test @ http://192.168.100.102:51996/api/hello
  2.   1 threads and 1 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency     2.76ms   14.97ms 200.26ms   98.45%
  5.     Req/Sec     1.54k   402.67     2.62k    73.74%
  6.   15294 requests in 10.07s, 16.07MB read
  7. Requests/sec:   1518.47
  8. Transfer/sec:      1.60MB
复制代码
测试过程,通过虚拟机(top 指令)和Windows(任务管理器)观察 cpu,发现没怎么动,看来 wrk 要跑满性能,得加量。
我们给虚拟机分了2个核,不能浪费,要跑满它,于是不断调整参数:
  1. wrk -t 2 -c4096 -d 10s http://192.168.100.102:51996/api/hello
复制代码
测试结果:qps = 23303 
  1. Running 10s test @ http://192.168.100.102:51996/api/hello
  2.   2 threads and 4096 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency    28.17ms   19.27ms 307.26ms   82.72%
  5.     Req/Sec    11.63k    12.33k   37.01k    77.53%
  6.   234427 requests in 10.06s, 246.37MB read
  7.   Socket errors: connect 3077, read 0, write 0, timeout 0
  8. Requests/sec:  23303.58
  9. Transfer/sec:     24.49MB
复制代码
从测试结果观察,wrk 更能压测出性能的极限,当然,这是 wrk 的极限,不是程序的极限。
因为整个压测过程,程序只占了30%左右的cpu,但没办法,cpu 让其它资源给吃光了。

我们知道,.NET Core 的程序,跑在 Linux 下,能会有更优的性能,不过不急先。
由于本机资源有限,干扰程序较多,这里打算拿出我的新电脑,来进行重新测试,看看程序在新电脑的表现如何。
二、新电脑环境:
  1. CPU    13th Gen Intel(R) Core(TM) i5-13600KF
  2. 内核:    14
  3. 逻辑处理器: 20
  4. 内存:64G
复制代码
接下来,我们看看新电脑的表现如何,使用一样的程序:
1、测试 Window 11 下,单机ab工具压测:

A、先测试单线程的运行性能(简单接口返回,控制台无日志输出):
  1. ab -n 100000 -c 1 http://192.168.100.102:51996/api/hello
复制代码
测试结果:并发数1,qps =  11389
  1. Concurrency Level:      1
  2. Time taken for tests:   0.878 seconds
  3. Complete requests:      10000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      1410000 bytes
  7. HTML transferred:       260000 bytes
  8. Requests per second:    11389.76 [#/sec] (mean)
  9. Time per request:       0.088 [ms] (mean)
  10. Time per request:       0.088 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          1568.32 [Kbytes/sec] received
复制代码
B、我们调整一下参数,看看ab在单机下能压出多少来(简单接口返回,控制台无日志输出):
  1. ab -n 100000 -c 4 http://192.168.100.101:51996/api/hello
复制代码
测试结果:并发数4,qps = 18247
  1. Concurrency Level:      4
  2. Time taken for tests:   5.480 seconds
  3. Complete requests:      100000
  4. Failed requests:        0
  5. Write errors:           0
  6. Total transferred:      14100000 bytes
  7. HTML transferred:       2600000 bytes
  8. Requests per second:    18247.09 [#/sec] (mean)
  9. Time per request:       0.219 [ms] (mean)
  10. Time per request:       0.055 [ms] (mean, across all concurrent requests)
  11. Transfer rate:          2512.54 [Kbytes/sec] received
复制代码
看来 ab 不行啊,压不出结果,程序的cpu才跑了不到2%。
小结:
  1. 虽然 ab 压测不够力,但从单线程的测试结果可以看出,新电脑的cpu运行效率是旧电脑性能的3倍左右,效率拉满。
  2. 以此看出,平时在采购云服务器时,也得顺带关注一下CPU的型号,好的型号,能提升运行效率,提高并发。
复制代码
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.101:51996/api/hello
复制代码
测试结果:1并发,qps = 14084
  1. Running 10s test @ http://192.168.100.101:51996/api/hello
  2.   1 threads and 1 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency     6.43ms   29.09ms 218.31ms   95.10%
  5.     Req/Sec    14.43k     3.27k   17.98k    91.84%
  6.   141377 requests in 10.04s, 21.71MB read
  7. Requests/sec:  14084.98
  8. Transfer/sec:      2.16MB
复制代码
和 ab 一样,一个链接并发压不出什么效果,加大效果看看。
  1. wrk -t 8 -c 2048 -d 10s http://192.168.100.101:51996/api/hello
复制代码
测试结果:qps = 84306
  1. Running 10s test @ http://192.168.100.101:51996/api/hello
  2.   28 threads and 2048 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency    11.40ms   10.81ms 222.31ms   86.60%
  5.     Req/Sec     5.35k     3.03k   18.81k    69.09%
  6.   850042 requests in 10.08s, 130.52MB read
  7.   Socket errors: connect 1051, read 0, write 100, timeout 0
  8. Requests/sec:  84306.38
  9. Transfer/sec:     12.94MB
复制代码
压测试过程,观察两个cpu,虚拟机(110%-130%,2核还没跑满),程序只跑16%-20%,整体40-50%左右,感觉还能往上跑。
估计是压力不够,试着分给虚拟机多2核,看看有没有效果。
虚拟机环境:
  1. CPU    13th Gen Intel(R) Core(TM) i5-13600KF
  2. 内核:    4
  3. 逻辑处理器: 4
  4. 内存:8G
复制代码
继续压测试:
  1. wrk -t18 -c 1400 -d 60s http://192.168.100.101:51996/api/hello
复制代码
测试结果:qps = 105462
  1. Running 1m test @ http://192.168.100.101:51996/api/hello
  2.   18 threads and 1400 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency    10.02ms   10.05ms 267.70ms   90.26%
  5.     Req/Sec     6.68k     3.31k   17.16k    62.65%
  6.   6339226 requests in 1.00m, 0.95GB read
  7.   Socket errors: connect 383, read 0, write 25, timeout 0
  8. Requests/sec: 105462.01
  9. Transfer/sec:     16.19MB
复制代码
之前压测时间在10s-20s,qps 都在9万多,把压测时间拉长到1分钟,超过了10万了。
看来把压测时间拉长,qps 会高一点。
测试过程中,虚拟机CPU(在180%左右,给了4核,也不顶用,没能跑满),程序占用CPU(20%左右)。
还是跑不满,没办法,压力上不去了,只好换个口味测试。
重新压测 CYQ.Data 读数据库转Json输出的接口(数据库mssql2012 安装在Window 11 本机):

接口的调用输出:

进行压测:
  1. wrk -t18 -c 1200 -d 60s http://192.168.100.101:51996/api/hellodb
复制代码
测试结果:qps = 73122
  1. Running 1m test @ http://192.168.100.101:51996/api/hellodb
  2.   18 threads and 1200 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency    47.62ms   86.25ms   1.15s    85.85%
  5.     Req/Sec     4.61k     2.10k   17.56k    68.95%
  6.   4394613 requests in 1.00m, 4.51GB read
  7.   Socket errors: connect 185, read 0, write 24, timeout 1
  8. Requests/sec:  73122.19
  9. Transfer/sec:     76.85MB
复制代码
再换一个,直接压 MVC 界面,看看效果。
这是压测试的 Taurus.MVC 的主界面:

修改压测路径:
  1. wrk -t18 -c 1200 -d 60s http://192.168.100.101:51996/home/index
复制代码
测试结果:qps = 39349
  1. Running 1m test @ http://192.168.100.101:51996/home/index
  2.   18 threads and 1200 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency    82.78ms  160.41ms   1.94s    87.98%
  5.     Req/Sec     2.33k     0.94k    7.67k    67.93%
  6.   2364614 requests in 1.00m, 8.75GB read
  7.   Socket errors: connect 185, read 0, write 0, timeout 918
  8. Requests/sec:  39349.00
  9. Transfer/sec:    149.13MB
复制代码
这时候观察,虽然取得了不错的结果,但 CPU 跑满100%了,也有918个超时,看来呈现的加载与呈现,很消耗计算量。
到了最后的步骤了,.NET Core 程序,还是得放到 Linux 系统下跑看看效果 ,复制一台虚拟机,用来部署 .NET Core 程序。
3、测试 CentOS 7 下,虚拟机 wrk 工具压测:

新的虚拟机环境:
  1. CPU    13th Gen Intel(R) Core(TM) i5-13600KF
  2. 内核:    8
  3. 逻辑处理器: 8
  4. 内存:8G
复制代码
1、测试接口:直接压测 CYQ.Data 读数据库转Json输出的接口(数据库mssql2012安装在Window 11 系统):
  1. wrk -t18 -c 1600 -d 60s http://192.168.100.111:51996/api/hellodb
复制代码
测试结果:qps = 80831
  1. Running 1m test @ http://192.168.100.111:51996/api/hellodb
  2.   18 threads and 1600 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency    35.63ms   74.47ms   1.03s    87.97%
  5.     Req/Sec     4.83k     2.67k   18.55k    69.03%
  6.   4856997 requests in 1.00m, 4.98GB read
  7.   Socket errors: connect 581, read 0, write 0, timeout 0
  8. Requests/sec:  80831.35
  9. Transfer/sec:     84.95MB
复制代码
观察CPU:压测虚拟机(130%左右,用了1.3个核左右),应用程序虚拟机(450%左右,用了4.5个核左右)
2、测试接口:直接测试简单接口
  1. wrk -t18 -c 1600 -d 60s http://192.168.100.111:51996/api/hello
复制代码
测试结果:qps = 105994
  1. Running 1m test @ http://192.168.100.111:51996/api/hello
  2.   18 threads and 1600 connections
  3.   Thread Stats   Avg      Stdev     Max   +/- Stdev
  4.     Latency     9.16ms    4.84ms 212.60ms   79.65%
  5.     Req/Sec     6.32k     3.65k   27.06k    57.03%
  6.   6424281 requests in 1.00m, 0.95GB read
  7.   Socket errors: connect 581, read 0, write 0, timeout 0
  8. Requests/sec: 106908.28
  9. Transfer/sec:     16.21MB
复制代码
观察CPU:和上一个结果差不多,只用了虚拟机的50%左右,就是部署在Linux 上,随便调整参数,都轻松10万+。
总结:

对于 API 压测:

旧电脑轻松就打满CPU,主要是被ab和其它应用吃了资源,所以压测上不去,去掉虚拟机两核后,在读数据库转Json输出的情况下,压出了2万3的qps。
新电脑上限太高,wrk 都压不住,上10万+了,CPU也才20%左右,可见一个高效的CPU对并发的提升是多么明显。
新电脑在读数据库转Json输出的情况下,也有8万+的qps,这个3倍左右的效率,明显的有点明显了。
最后部署在 Linux,可以感觉性能明显比 Window 运行高一些,Window 需要小小调优参数才10万+,而 Linux 上随便调都10万+。
但因wrk给的压力也有限,10万+后无法再测试了,听说 ulimit -n 命令可以解锁,发起更大的并发,这个下次再试了。
对于 MVC 压测:

明显感觉 MVC 的计算量大了很多,wrk 提供的压力已足够跑满CPU,极限跑出近4万的qps,感觉后续应该还能小优化一下。
整体来说,今天的压力测试结果,除了压测试MVC界面,CPU 压满了,而压测试API,CPU 都没能跑满整机的30%,心累啊,先就到这里了。
附本文的运行程序:TaurusMVC运行程序下载 - 解压后可直接运行 Taurus.View.exe,欢迎下载自行测试【需要.NET 8 运行环境】

 

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

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x

举报 回复 使用道具