前言:

最近的 Taurus.MVC 版本,对性能这一块有了不少优化,因此准备进行一下压测,来测试并记录一下 Taurus.MVC 框架的性能,以便后续持续优化改进。

今天先压测 .NET Core 版本,后续有时间再压测一下.NET 版本。

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

一、旧电脑环境:

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

程序在 .NET8 编绎,以 Kestrel 为主机直接运行在 Window 环境:

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

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

ab的版本信息:

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 [ms] (mean)
Time per request: 0.306 [ms] (mean, across all concurrent requests)
Transfer rate: 443.01 [Kbytes/sec] received

看一下程序运行的时间:

从程序打印的日志上看,接口执行时间仅有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 [ms] (mean)
Time per request: 0.182 [ms] (mean, across all concurrent requests)
Transfer rate: 746.35 [Kbytes/sec] 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 [ms] (mean)
Time per request: 0.278 [ms] (mean, across all concurrent requests)
Transfer rate: 488.06 [Kbytes/sec] 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 [ms] (mean)
Time per request: 0.173 [ms] (mean, across all concurrent requests)
Transfer rate: 782.66 [Kbytes/sec] 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());
}
}

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

下面直接进行压测结果:并发数 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 [ms] (mean)
Time per request: 0.183 [ms] (mean, across all concurrent requests)
Transfer rate: 5774.73 [Kbytes/sec] 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 让其它资源给吃光了。

我们知道,.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 [ms] (mean)
Time per request: 0.088 [ms] (mean, across all concurrent requests)
Transfer rate: 1568.32 [Kbytes/sec] received

B、我们调整一下参数,看看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 [ms] (mean)
Time per request: 0.055 [ms] (mean, across all concurrent requests)
Transfer rate: 2512.54 [Kbytes/sec] 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 本机):

接口的调用输出:

进行压测:

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 的主界面:

修改压测路径:

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.78ms 160.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
内存:8G

1、测试接口:直接压测 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 运行环境】

Taurus.MVC 性能压力测试(ap 压测 和 linux 下wrk 压测):.NET Core 版本的更多相关文章

  1. JMeter工具接口性能压力测试分析与优化

    最近公司做的项目,要求对相关接口做性能压力测试,在这里记录一下分析解决过程. 压力测试过程中,如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大,TPS逐渐降低等.而问题定位分析通常情 ...

  2. Web服务器性能压力测试工具http_load、webbench、ab、Siege使用教程

    Web服务器性能压力测试工具http_load.webbench.ab.Siege使用教程 作者: feng 日期: 2012/07/25 发表评论 (0) 查看评论   一.http_load 程序 ...

  3. 山东BOSS性能压力测试

    1. 概述 在山东BOSS性能压力测试过程中,发现脚本对于整个压力测试过程的重要性,一个压力测试脚本录制和编辑修改得怎么样直接影响后面压力测试的执行.通常情况下,脚本应尽可能的精简,就像写代码一样.针 ...

  4. 三种web性能压力测试工具

    三种web性能压力测试工具http_load webbench ab小结 题记:压力和性能测试工具很多,下文讨论的是我觉得比较容易上手,用的比较多的三种 http_load 下载地址:http://w ...

  5. 【转】Web性能压力测试工具之ApacheBench(ab)详解

    PS:网站性能压力测试是性能调优过程中必不可少的一环.只有让服务器处在高压情况下才能真正体现出各种设置所暴露的问题.Apache中有个自带的,名为ab的程序,可以对Apache或其它类型的服务器进行网 ...

  6. [AapacheBench工具]web性能压力测试工具的应用与实践

    背景:网站性能压力测试是性能调优过程中必不可少的一环.服务器负载太大而影响程序效率是很常见的事情,一个网站到底能够承受多大的用户访问量经常是我们最关心的问题.因此,只有让服务器处在高压情况下才能真正体 ...

  7. Web性能压力测试工具之ApacheBench(ab)详解

    PS:网站性能压力测试是性能调优过程中必不可少的一环.只有让服务器处在高压情况下才能真正体现出各种设置所暴露的问题.Apache中有个自带的,名为ab的程序,可以对Apache或其它类型的服务器进行网 ...

  8. Web性能压力测试工具之Apache AB 详解

    下载安装地址: http://httpd.apache.org/download.cgi yum install httpd-tools http://www.apachelounge.com/dow ...

  9. Web服务器性能/压力测试工具http_load、webbench、ab、Siege使用教程 - VPS侦探

    Web服务器性能/压力测试工具http_load.webbench.ab.Siege使用教程 - VPS侦探 http://soft.vpser.net/test/http_load/http_loa ...

  10. [转] Web性能压力测试工具之ApacheBench(ab)详解

    PS:网站性能压力测试是性能调优过程中必不可少的一环.只有让服务器处在高压情况下才能真正体现出各种设置所暴露的问题.Apache中有个自带的,名为ab的程序,可以对Apache或其它类型的服务器进行网 ...

随机推荐

  1. Error creating bean with name 'XXX': Bean with name 'senseOneToSomeFeignImpl' has been injected into other beans [XXXXXX] in its raw version as part of a circular reference

    关于Spring框架中的循环依赖问题,您可以尝试以下几种方法来解决: 重新定义Bean依赖:重构代码以消除循环依赖.这可能涉及重新设计类,使它们不相互依赖即可运行. 使用Setter注入:与构造函数注 ...

  2. 使用grafana+Prometheus监控时PromQL内置函数详解

    1.Prometheus简介 Prometheus(中文名:普罗米修斯)是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB). Prometheus使用Go语言开发, 是Googl ...

  3. 开源:Taurus.Idempotent 分布式幂等性锁框架,支持 .Net 和 .Net Core 双系列版本

    分布式幂等性锁介绍: 分布式幂等性框架的作用是确保在分布式系统中的操作具有幂等性,即无论操作被重复执行多少次,最终的结果都是一致的.幂等性是指对同一操作的多次执行所产生的效果与仅执行一次的效果相同. ...

  4. java项目-尚硅谷项目三员工调度系统

    导入工具类和数据 创建TeamSchedule项目,com.atguigu.team. view,com.atguigu.team.service,com.atguigu.team.domain包 , ...

  5. I/O系统调用

    常用系统调用 open #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int op ...

  6. 键鼠共享工具使用(软KVM)-barrier(symless开源版)

    作用:通过软件方式,实现KVM,即一套键盘鼠标可以控制多台电脑,并可以进行粘贴板共享. 1.安装 打开https://github.com/debauchee/barrier,进releases下载对 ...

  7. Miracast技术详解(三):RTP & MPEG2-TS

    目录 Miracast音视频流概述 抓包准备 RTP MPEG2-TS TS分组 适配域 PCR PID PSI PAT PMT PES 总结 Miracast音视频流概述 在上一篇文章中,我们已经成 ...

  8. Django:Nginx 启动,无法加载样式,无法加载静态文件

    一般是由于 Nginx 配置文件的问题 # 编辑 Nginx 配置文件 vim /etc/nginx/nginx.conf # 如果出现下面这个 use nginx 就需要改成 use root 保存 ...

  9. 【Mahjong hdu 枚举】搜索枚举

    #####枚举 import java.io.*; import java.util.*; public class Main { static HashSet<String> set1; ...

  10. 写了个简单爬虫,分析 Boss 直聘自动驾驶岗位

    两年前,朋友想知道 Boss 直聘上关于自动驾驶的岗位有哪些 ,于是,笔者写了一个简单的爬虫 crawler-boss ,将岗位的信息收集起来. 这篇文章,笔者想分享爬虫 crawler-boss 的 ...