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

最新推荐文章于 2024-08-27 15:22:40 发布
最新推荐文章于 2024-08-27 15:22:40 发布
阅读量408 收藏 9
点赞数 4
分类专栏： ASP.NET Taurus.MVC 系列 文章标签： mvc 压力测试 linux .net
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cyq1162/article/details/137816850
版权

前言：

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

.net core 的性能以及大名鼎鼎的QPS
网尘的技术专栏
11-09 9782
华丽的目录1、官方的测试结果LinuxWindows2、真正的生产环境3、结论引用链接 1、官方的测试结果 以下结果来自 .net core官方的benchmarks摘录。 Linux 编号 对比方 系统环境 宿主环境 测试结果（QPS） 1 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 26.7k vs 1.57k ...
jmeter结合Taurus分布式压测
weixin_39246324的博客
04-21 2817
前提条件： 服务器上都安装了Taurus 服务器上使用的jmeter版本都一致（~/.bzt/jmeter-taurus/下有相同的jmeter版本） 开始配置：选择一台服务器作为主机，其他服务器作为从属机器 一、主机上的配置修改 1.编辑配置文件 vim ~/.bzt/jmeter-taurus/5.3（jmeter版本号）/bin/jmeter.properties remote_hosts=localhost:1099,xxx.xx.xx.xx:1099,x.x.x.x:1099
Taurus入门，这么神奇的性能测试工具不能不知道
qq_60168783的博客
02-25 1821
一、前言 　　相信大家对这个工具都很陌生，国内能搜索到的资料很少，那么为什么突然推荐想起来这个工具呢？第一，我觉得它很好用；第二，为后面介绍的服务端性能自动化框架铺成。 　　二、Taurus简介 　　Taurus 是 BlazeMeter 的核心组件，其是一个开源自动化框架，用于运行各种开源负载测试工具和功能测试工具，支持的最流行开源压测工具有 JMeter、Selenum、Gatling、The Grnder、Locust 等。 　　官网：https://gettaurus.org/ 　　其
性能工具之Taurus入门（安装篇）
Mo小泽的技术博客
10-24 3741
文章目录前言Taurus简介为什么推荐？环境准备安装 python3.x安装pip3.x安装Taurus常规安装Docker Image小结 前言 相信大家对这个工具都很陌生，国内能搜索到的资料很少，那么为什么突然推荐想起来这个工具呢？第一，我觉得它很好用；第二，为后面介绍的服务端性能自动化框架铺成。 Taurus简介 Taurus是 BlazeMeter 的核心组件，其是一个开源自动化框架，用...
wrk性能测试工具
Yang19950816的博客
08-27 973
使用-H参数可以添加自定义的 HTTP 请求头。例如，wrk -H "Authorization: Bearer token" 可以添加 Authorization 头。wrk 还支持使用 Lua 脚本进行更复杂的测试场景。通过编写 Lua 脚本，可以实现更多定制化的功能和测试场景，例如：模拟不同类型的请求：通过Lua脚本可以模拟不同类型的请求，包括等，并携带不同的请求参数和请求体。实现复杂的请求逻辑：可以在 Lua 脚本中实现复杂的请求逻辑，包括动态生成请求数据、处理响应数据等。
性能测试之压力测试
酷酷的馫博客
09-15 1540
压力测试考察当前软硬件条件下系统所能承受的最大负荷并找到系统瓶颈所在。压测是为了系统在线上的处理能力和稳定性维持在一个范围内。内存泄漏、并发与同步。
Taurus.MVC:Taurus.mvc is a high-performance mvc and webapi framework for asp.net or asp.net core（适合场景：对性能和并发有较高要求的电商、站点、WebAPI等系统，支持.Net Core）
05-13
Taurus.mvc是用于asp.net或asp.net核心（适合场景：对性能和并发有较高要求的电商，站点，WebAPI等系统，支持.Net核心）的高性能mvc和webapi框架，已创建通过Aster（路过秋天） QQ交流群：6033006 Windows部署： :...
asp.net的MVC框架Taurus.MVC.zip
07-17
Taurus.MVC是一个简单的asp.net的MVC框架。 标签：Taurus Web框架
Taurus.MVC 如何升级并运行在NET6、NET7
路过秋天 - 理想很美好，现实很残酷，坚持在路上，只因初心仍存
07-22 586
最近看到NET7也出来了，其中启动程序，合并了Program和Startup，因此，补上一下Taurus.MVC在NET6、7的运行教程
Taurus.MVC WebAPI 入门开发教程1：框架下载环境配置与运行（含系列目录）。
m0_56069948的博客
08-04 294
Taurus.MVC V3.0.3 微服务开源框架发布：让.NET 架构在大并发的演进过程更简单。以前都是框架发布时写点相关功能点的文章，没有形成系列。因此，计划补充些详细的入门开发教程，本系列教程目录如下：1、Taurus.MVC WebAPI 入门开发教程1：框架下载环境配置与运行。2、Taurus.MVC WebAPI 入门开发教程2：添加控制器输出Hello World。3、Taurus.MVC WebAPI 入门开发教程3：路由类型和路由映射。...
Taurus.MVC-Java 版本打包上传到Maven中央仓库（详细过程）：1、JIRA账号注册
java1527的博客
09-08 732
本篇讲述如何将一个框架打包上传到中央仓库。经过九九八十一难，终于成功打包上传，特此记录与分享。如果无法顺利，遇到问题，建议多参考官网指南，即下文中系统给到的评论的指南地址。1、注册好账号，并审核通过后，后续配置settings.xml会用到用户名和密码。2、 接下来的流程，不管是网上的，还是官网的，都讲述的不够清楚明白。3、个人是参考网上和官网，重新总结摸索了一条新路，仅供参考。
taurus, 自动化友好的连续测试框架.zip
09-18
taurus, 自动化友好的连续测试框架 快速链接：Taurus文档 | 知识基础| 支持论坛命令行目使用自动化友好的包装器隐藏性能和功能测试的复杂性。 金牛座依靠 JMeter 。Gatling 。Locust.io, 磨床和 Selenium WebDriver 作
taurus:通过自动化友好的框架进行连续测试
05-11
金牛座 快速链接： | | 目的 通过自动化友好的便捷包装器隐藏了性能和功能测试的复杂性。 Taurus依靠JMeter，Gatling，Locust.io，Grinder和Selenium WebDriver作为其基础工具。 在Apache 2.0许可下免费和开源。 安装或升级 只需使用PyPi安装它： pip install bzt 有关Linux，Mac OS和Windows的更多详细说明，请。 入门 创建一个名为test.yml的文件，其内容如下： --- execution : - concurrency : 10 ramp-up : 1m hold-for : 1m30s scenario : simple scenarios : simple : think-time : 0.75 requests : - http://blazed
在Linux里wrk的路径,linux下wrk的安装
weixin_39639381的博客
05-03 841
wrk是linux下开源的性能测试工具，并且只能在linux下运行，下面介绍下安装教程(以ubantu18.04环境为例)：1.预先安装git，如:apt install git2.从git上拉取wrk：git clone https://github.com/wg/wrk.git wrk3.cd wrk4.apt-get install build-essential -y5.make6.把生成...
极简的wrk安装和使用教程
Hi，我是sharkchili，CSDN Java领域博客专家，开源项目JavaGuide维护人员，我想写一些有意思的东西，希望对你有帮助。
12-16 2281
wrk 是一款针对 Http 协议的基准测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。是一款轻量级性能测试工具。安装简单（相对 Apache ab 来说）。学习曲线基本为零，简单了解一下使用参数就可以上手干活了。基于系统自带的高性能 I/O 机制，如 epoll, kqueue, 利用异步的事件驱动框架，通过很少的线程就可以压出很大的并发量。
Taurus.MVC 性能压力测试（ap 压测 和 linux 下wrk 压测）：.NET Core 版本
路过秋天 - 理想很美好，现实很残酷，坚持在路上，只因初心仍存
04-12 727
旧电脑轻松就打满CPU，主要是被ab和其它应用吃了资源，所以压测上不去，去掉虚拟机两核后，在读数据库转Json输出的情况下，压出了2万3的qps。新电脑上限太高，wrk 都压不住，上10万+了，CPU也才20%左右，可见一个高效的CPU对并发的提升是多么明显。新电脑在读数据库转Json输出的情况下，也有8万+的qps，这个3倍左右的效率，明显的有点明显了。最后部署在 Linux，可以感觉性能明显比 Window 运行高一些，Window 需要小小调优参数才10万+，而 Linux 上随便调都10万+
使用wrk压测，找到最大qps
qq_24381917的博客
05-21 2047
使用wrk进行压测 运行simple_server，进入服务器wrk目录下 使用命令进行第一次压测 ```./wrk -c 10 -t 8 -d 60 http://localhost:3456/ping`` qps为5618.3 3.增加并发数到20，使用命令 ./wrk -c 20 -t 8 -d 60 http://localhost:3456/ping qps为5774.34 4.增加并发数到30，使用命令 ./wrk -c 30 -t 8 -d 60 http://localhost:34
使用 wrk 对 http 接口进行压测并 计算其 TPS
csx2804498964的博客
12-11 1284
背景: wrk 是当今最流行的 HTTP 压测工具，用于模拟高并发情况下的 HTTP 请求。wrk 使用 Lua 作为脚本语言，可以通过编写 Lua 脚本来自定义请求的参数和逻辑。它支持多线程并发请求，并提供了丰富的统计信息和报告，可以帮助你评估服务器的性能和承受能力。本贴致力于最快速让你上手wrk。看完本贴，你将学会使用 wrk 对 http 接口进行压测, 并计算其 TPS 指标。
性能测试工具——wrk的安装与使用
2401_83014911的博客
05-10 1043
想和大家来聊聊性能测试，聊到了性能测试必须要说的是性能测试中的工具，在这些工具中我今天主要给大家介绍wrk。wrk是一款开源的性能测试工具，简单易用，没有Load Runner那么复杂，他和 apache benchmark（ab）同属于性能测试工具，但是比 ab 功能更加强大，并且可以支持lua脚本来创建复杂的测试场景。wrk 的一个很好的特性就是能用很少的线程压出很大的并发量， 原因是它使用了一些操作系统特定的高性能 I/O 机制, 比如 select, epoll, kqueue 等。
modbus协议压测
最新发布
08-30
1. **选择工具**：可以使用像Lagommer、Taurus、JMeter等压力测试工具，它们支持Modbus TCP/IP或串口通信协议的模拟。 2. **设置测试场景**：配置目标地址、功能码（Function Codes）、数据结构等，模拟真实的设备...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值