前言:

上次发布了: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 运行程序

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

  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. powershell配置自动补全

    powershell配置自动补全 一.需求: 看到老师上课用mac命令行有自动补全功能,发现真的爽.但是自己的windows powershell不能使用自动补全功能.有了需求,就想找到能完成目前的任 ...

  2. 从0开始搭建开发环境 -实现servlet原生开发

    开发环境:  JDK1.8 + Servlet + Mysql 搭建项目 项目搭建参考博客 https://www.cnblogs.com/oyww-2027/p/15347137.html File ...

  3. inner join on 1=1 在查询中的高级用法

    最近在项目中看到一个查询语句,让我有兴趣去研究.研究.查询语句如下: 重点分析第二个INNER JOIN  ON 1 = 1 这个语句:内连接表示查询两个表的交集,而且ON的条件为 1=1 就表示连接 ...

  4. git 全局用户名改为英文,中文生成的git记录文件 不能有中文,现场反馈 git config user.name

    设置用户名和邮箱 git config --global user.name "username" git config --global user.email useremail ...

  5. pod为什么会被驱逐及如何避免pod被驱逐导致的服务中断

    Pod被驱逐的原因主要有以下几点: 资源不足:当节点资源(如CPU.内存.存储等)不足以满足Pod的资源需求时,调度器会选择将其中一个或多个Pod驱逐出节点,以便在资源有限的节点上安排新的Pod. 超 ...

  6. arch签名出现问题时,无法修复时

    sudo rm -rf /etc/pacman.d/gnupgsudo pacman-key --init sudo pacman-key --populate archlinux && ...

  7. SQL注入详细讲解概括—盲注

    SQL注入详细讲解概括-盲注 1.盲注简单理解 2.盲注必学函数 3.布尔盲注 4.时间盲注 一.盲注简单理解 What is 盲注? It is 在服务器没有错误回显的时候完成的注入攻击 数据库把报 ...

  8. 自己动手做一个批量doc转换为docx文件的小工具

    前言 最近遇到了一个需求,就是要把大量的doc格式文件转换为docx文件,因此就动手做了一个批量转换的小工具. 背景 doc文件是什么? "doc" 文件是一种常见的文件格式,通常 ...

  9. Python利用pandas拆分大型的csv文件

    当将大型CSV文件拆分成较小的文件时,您可以使用Python的Pandas库来处理 导入必要的库 import pandas as pd 定义拆分函数 当定义拆分函数时,我们将在以下步骤中处理CSV文 ...

  10. nginx 自定义日志格式输出

    修改 nginx.conf 自定义日志格式.路径 log_format my_format '$remote_addr $msec $http_host $request_uri'; 使用精准配准,对 ...