Taurus.MVC 性能压力测试（ap 压测 和 linux 下wrk 压测）：.NET Core 版本
前言：近来的 Taurus.MVC 版本，对性能这一块有了不少优化，因此准备进行一下压测，来测试并记录一下 Taurus.MVC 框架的性能，以便后续连续优化改进。
今天先压测 .NET Core 版本，后续有时间再压测一下.NET 版本。
下面来看不同场景下的压测结果，以下测试结果会由两台电脑进行分别测试。
一、旧电脑环境：
CPU ：Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
内核: 6
逻辑处理器: 6<br>内存：16G步调在 .NET8 编绎，以 Kestrel 为主机直接运行在 Window 环境：
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409155607546-305816188.png
1、测试 Window 11 下，单机ab工具压测：
由于ab工具占用资源不多，发起的并发能力也有限，先用它进行本机压测，试试水。
ab的版本信息：
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409164216797-820998116.png
A、先测试单线程的运行性能（简朴接口返回，控制台带日志输出）：
ab -n 100000 -c 1 http://192.168.100.102:51996/api/hello测试结果：并发数1，qps = 3263
Server Software:
Server Hostname: 192.168.100.102
Server Port: 51996
Document Path: /api/hello
Document Length: 24 bytes
Concurrency Level: 1
Time taken for tests: 30.641 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 13900000 bytes
HTML transferred: 2400000 bytes
Requests per second: 3263.63 [#/sec] (mean)
Time per request: 0.306 (mean)
Time per request: 0.306 (mean, across all concurrent requests)
Transfer rate: 443.01 received看一下步调运行的时间：
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409160316298-110295476.png
从步调打印的日志上看，接口执行时间仅有0.03毫秒，理论值单线程压测是可以达到1000/0.0345= 28089，
去掉控制器日志输出，还能再提拔1下，再设置个64核cpu，就是传说中的轻轻松松的单机百万qps了。
B、我们调整一下参数，看看ab在单机下能压出多少来（简朴接口返回，控制台带日志输出）：
ab -n 100000 -c 2 http://192.168.100.102:51996/api/hello测试结果：
Concurrency Level: 2
Time taken for tests: 18.187 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 13900000 bytes
HTML transferred: 2400000 bytes
Requests per second: 5498.28 [#/sec] (mean)
Time per request: 0.364 (mean)
Time per request: 0.182 (mean, across all concurrent requests)
Transfer rate: 746.35 received没办法，只能压 2 个并发链接，CPU 跑满了，步调占40%多，ab也占了40%多，说好的ab不吃资源的，直接cpu拉走一半，呵呵。
C、我们关闭日志输出，重新看看上面的两个能测试出多少（简朴接口返回，控制台无日志输出）：
我们添加以下代码，关闭 Kestrel 默认的控制台信息输出：
services.AddLogging(op => op.SetMinimumLevel(LogLevel.None));【后续的测试，都保持控制器日志关闭】
重新编绎后，进行重新测试：
测试结果：并发数1，qps = 3595
Concurrency Level: 1
Time taken for tests: 2.781 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1390000 bytes
HTML transferred: 240000 bytes
Requests per second: 3595.51 [#/sec] (mean)
Time per request: 0.278 (mean)
Time per request: 0.278 (mean, across all concurrent requests)
Transfer rate: 488.06 received关闭日志，提拔了300多，后续测试，将会保持控制台日志的关闭。
测试结果：并发数 2，qps = 5765
Concurrency Level: 2
Time taken for tests: 1.734 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1390000 bytes
HTML transferred: 240000 bytes
Requests per second: 5765.77 [#/sec] (mean)
Time per request: 0.347 (mean)
Time per request: 0.173 (mean, across all concurrent requests)
Transfer rate: 782.66 received接下来，我们将接口调整一下，单纯的返回 Hello World 没啥看头，改成常规一些。
D、利用 CYQ.Data 读数据库，输出 Json，来看看压测结果（读数据库接口，控制台无日志输出）
测试代码：
public void Hello(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());
}
}运行结果：返回一条数据：
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409163601504-230328221.png
下面直接进行压测结果：并发数 2 ，qps = 5470，和未关闭日志输出时差不多。
Concurrency Level: 2
Time taken for tests: 1.828 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 10810000 bytes
HTML transferred: 9590000 bytes
Requests per second: 5470.23 [#/sec] (mean)
Time per request: 0.366 (mean)
Time per request: 0.183 (mean, across all concurrent requests)
Transfer rate: 5774.73 received小结：
从上面的测试结果，观察CPU中可以看出，ab 这个工具，吃 cpu 资源不说，其并发数量也有限。下面更换 wrk 进行测试，由于 wrk 只能在 linux 中运行，因此在本机上，开启了虚拟机。
2、测试 Window 11 下，虚拟机wrk工具压测：（读数据库输出，控制台无日志输出）
虚拟机环境：
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.102:51996/api/hello测试结果：qps = 1518
Running 10s test @ http://192.168.100.102:51996/api/hello
1 threads and 1 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 2.76ms 14.97ms 200.26ms 98.45%
Req/Sec 1.54k 402.67 2.62k 73.74%
15294 requests in 10.07s, 16.07MB read
Requests/sec: 1518.47
Transfer/sec: 1.60MB测试过程，通过虚拟机（top 指令）和Windows（使命管理器）观察 cpu，发现没怎么动，看来 wrk 要跑满性能，得加量。
我们给虚拟机分了2个核，不能浪费，要跑满它，于是不断调整参数：
wrk -t 2 -c4096 -d 10s http://192.168.100.102:51996/api/hello测试结果：qps = 23303
Running 10s test @ http://192.168.100.102:51996/api/hello
2 threads and 4096 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 28.17ms 19.27ms 307.26ms 82.72%
Req/Sec 11.63k 12.33k 37.01k 77.53%
234427 requests in 10.06s, 246.37MB read
Socket errors: connect 3077, read 0, write 0, timeout 0
Requests/sec:23303.58
Transfer/sec: 24.49MB从测试结果观察，wrk 更能压测出性能的极限，固然，这是 wrk 的极限，不是步调的极限。
因为整个压测过程，步调只占了30%左右的cpu，但没办法，cpu 让其它资源给吃光了。
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409171302541-664689.png
我们知道，.NET Core 的步调，跑在 Linux 下，能会有更优的性能，不外不急先。
由于本机资源有限，干扰步调较多，这里打算拿出我的新电脑，来进行重新测试，看看步调在新电脑的体现如何。
二、新电脑环境：
CPU 13th Gen Intel(R) Core(TM) i5-13600KF
内核: 14
逻辑处理器: 20
内存：64G接下来，我们看看新电脑的体现如何，利用一样的步调：
1、测试 Window 11 下，单机ab工具压测：
A、先测试单线程的运行性能（简朴接口返回，控制台无日志输出）：
ab -n 100000 -c 1 http://192.168.100.102:51996/api/hello测试结果：并发数1，qps = 11389
Concurrency Level: 1
Time taken for tests: 0.878 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1410000 bytes
HTML transferred: 260000 bytes
Requests per second: 11389.76 [#/sec] (mean)
Time per request: 0.088 (mean)
Time per request: 0.088 (mean, across all concurrent requests)
Transfer rate: 1568.32 receivedB、我们调整一下参数，看看ab在单机下能压出多少来（简朴接口返回，控制台无日志输出）：
ab -n 100000 -c 4 http://192.168.100.101:51996/api/hello测试结果：并发数4，qps = 18247
Concurrency Level: 4
Time taken for tests: 5.480 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 14100000 bytes
HTML transferred: 2600000 bytes
Requests per second: 18247.09 [#/sec] (mean)
Time per request: 0.219 (mean)
Time per request: 0.055 (mean, across all concurrent requests)
Transfer rate: 2512.54 received看来 ab 不行啊，压不出结果，步调的cpu才跑了不到2%。
小结：
虽然 ab 压测不够力，但从单线程的测试结果可以看出，新电脑的cpu运行效率是旧电脑性能的3倍左右，效率拉满。
以此看出，平时在采购云服务器时，也得顺带关注一下CPU的型号，好的型号，能提升运行效率，提高并发。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.101:51996/api/hello测试结果：1并发，qps = 14084
Running 10s test @ http://192.168.100.101:51996/api/hello
1 threads and 1 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 6.43ms 29.09ms 218.31ms 95.10%
Req/Sec 14.43k 3.27k 17.98k 91.84%
141377 requests in 10.04s, 21.71MB read
Requests/sec:14084.98
Transfer/sec: 2.16MB和 ab 一样，一个链接并发压不出什么结果，加大结果看看。
wrk -t 8 -c 2048 -d 10s http://192.168.100.101:51996/api/hello测试结果：qps = 84306
Running 10s test @ http://192.168.100.101:51996/api/hello
28 threads and 2048 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 11.40ms 10.81ms 222.31ms 86.60%
Req/Sec 5.35k 3.03k 18.81k 69.09%
850042 requests in 10.08s, 130.52MB read
Socket errors: connect 1051, read 0, write 100, timeout 0
Requests/sec:84306.38
Transfer/sec: 12.94MB压测试过程，观察两个cpu，虚拟机（110%-130%，2核还没跑满），步调只跑16%-20%，整体40-50%左右，感觉还能往上跑。
估计是压力不敷，试着分给虚拟机多2核，看看有没有用果。
虚拟机环境：
CPU 13th Gen Intel(R) Core(TM) i5-13600KF
内核: 4
逻辑处理器: 4
内存：8G继续压测试：
wrk -t18 -c 1400 -d 60s http://192.168.100.101:51996/api/hello测试结果：qps = 105462
Running 1m test @ http://192.168.100.101:51996/api/hello
18 threads and 1400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 10.02ms 10.05ms 267.70ms 90.26%
Req/Sec 6.68k 3.31k 17.16k 62.65%
6339226 requests in 1.00m, 0.95GB read
Socket errors: connect 383, read 0, write 25, timeout 0
Requests/sec: 105462.01
Transfer/sec: 16.19MB之前压测时间在10s-20s，qps 都在9万多，把压测时间拉长到1分钟，凌驾了10万了。
看来把压测时间拉长，qps 会高一点。
测试过程中，虚拟机CPU（在180%左右，给了4核，也不顶用，没能跑满），步调占用CPU（20%左右）。
还是跑不满，没办法，压力上不去了，只好换个口味测试。
重新压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012 安装在Window 11 本机）：
接口的调用输出：
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409202720961-1511141466.png
进行压测：
wrk -t18 -c 1200 -d 60s http://192.168.100.101:51996/api/hellodb测试结果：qps = 73122
Running 1m test @ http://192.168.100.101:51996/api/hellodb
18 threads and 1200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 47.62ms 86.25ms 1.15s 85.85%
Req/Sec 4.61k 2.10k 17.56k 68.95%
4394613 requests in 1.00m, 4.51GB read
Socket errors: connect 185, read 0, write 24, timeout 1
Requests/sec:73122.19
Transfer/sec: 76.85MB再换一个，直接压 MVC 界面，看看结果。
这是压测试的 Taurus.MVC 的主界面：
https://img2024.cnblogs.com/blog/17408/202404/17408-20240409193841507-1837234500.png
修改压测路径：
wrk -t18 -c 1200 -d 60s http://192.168.100.101:51996/home/index测试结果：qps = 39349
Running 1m test @ http://192.168.100.101:51996/home/index
18 threads and 1200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 82.78ms160.41ms 1.94s 87.98%
Req/Sec 2.33k 0.94k 7.67k 67.93%
2364614 requests in 1.00m, 8.75GB read
Socket errors: connect 185, read 0, write 0, timeout 918
Requests/sec:39349.00
Transfer/sec: 149.13MB这时候观察，固然取得了不错的结果，但 CPU 跑满100%了，也有918个超时，看来呈现的加载与呈现，很消耗计算量。
到了最后的步调了，.NET Core 步调，还是得放到 Linux 体系下跑看看结果 ，复制一台虚拟机，用来部署 .NET Core 步调。
3、测试 CentOS 7 下，虚拟机 wrk 工具压测：
新的虚拟机环境：
CPU 13th Gen Intel(R) Core(TM) i5-13600KF
内核: 8
逻辑处理器: 8
内存：8G1、测试接口：直接压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012安装在Window 11 体系）：
wrk -t18 -c 1600 -d 60s http://192.168.100.111:51996/api/hellodb测试结果：qps = 80831
Running 1m test @ http://192.168.100.111:51996/api/hellodb
18 threads and 1600 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 35.63ms 74.47ms 1.03s 87.97%
Req/Sec 4.83k 2.67k 18.55k 69.03%
4856997 requests in 1.00m, 4.98GB read
Socket errors: connect 581, read 0, write 0, timeout 0
Requests/sec:80831.35
Transfer/sec: 84.95MB观察CPU：压测虚拟机（130%左右，用了1.3个核左右），应用步调虚拟机（450%左右，用了4.5个核左右）
2、测试接口：直接测试简朴接口
wrk -t18 -c 1600 -d 60s http://192.168.100.111:51996/api/hello测试结果：qps = 105994
Running 1m test @ http://192.168.100.111:51996/api/hello
18 threads and 1600 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 9.16ms 4.84ms 212.60ms 79.65%
Req/Sec 6.32k 3.65k 27.06k 57.03%
6424281 requests in 1.00m, 0.95GB read
Socket errors: connect 581, read 0, write 0, timeout 0
Requests/sec: 106908.28
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://img2024.cnblogs.com/blog/17408/202404/17408-20240409224131077-878629840.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]