广西住房与城乡建设厅网站电话,nginx即代理又做网站,门户网站建设目标,山西项目网1. 前言通过之前的学习#xff0c;我们已经掌握了crank的配置以及对应http基准工具bombardier、wrk、wrk2的用法#xff0c;本篇文章介绍一下如何将其用于实战#xff0c;在实际的项目中我们如何使用crank来完成压测任务。2. 项目背景目前有一个项目#xff0c;我们希望通过… 1. 前言通过之前的学习我们已经掌握了crank的配置以及对应http基准工具bombardier、wrk、wrk2的用法本篇文章介绍一下如何将其用于实战在实际的项目中我们如何使用crank来完成压测任务。2. 项目背景目前有一个项目我们希望通过压测来了解其QPS、吞吐量、以及临界值并通过压测来分析出其瓶颈在哪里并通过解决瓶颈问题以提高QPS、吞吐量等指标先看下我们手头掌握了什么项目信息项目中的接口基本都需要登录通过与开发沟通可以得到每个页面的接口信息以及参数信息环境信息压测项目有单独的环境部署应用、Redis、数据库等基础配置此处项目名我们暂定为ProjectA。3. 如何开展首先我们先回顾一下Agent、Controller的职责以及特点Controller做任务调度以及结果输出无需单独服务器可以在本机执行发送命令需要与Agent相通Agent任务的实际执行者单任务执行不能做到接收到多个任务并同时执行先收到哪个任务哪个任务会先执行相同一个任务可以被多个Agent同时执行最终指标结果会自动累加可以通过提升Agent来模拟更高的并发能力3.1. 思路先做好单独接口的压测大概掌握每个接口的指标情况同时压测多个接口完成对场景的压测通过压测观察应用服务器、基础服务器的CPU、带宽、内存等指标观察Redis、数据库、消息队列等基础组件情况根据压测的返回结果得到每个场景的基础指标通过分析发现瓶颈、然后再考虑如何突破瓶颈提升QPS、吞吐量等3.2. 如何做了解到单个Agent同时执行多个任务会进行排队无法做到多任务同时执行那么我们可以通过多个Agent同时执行不同的任务来模拟用户访问页面。3.2.1. 构建Agent之前与开发沟通得到每个页面最多可发送的请求是6个那么我们准备6个Agent分别为Agent1、Agent2、Agent3、Agent4、Agent5、Agent6我们这里使用Docker来启动Agent、Agent对内开放端口: 5010、对外端口随机镜像使用我们自建的: doddgu/crankagent:net5.0并新建load.yml为之后压测使用:profiles:crankAgent1:jobs:load:endpoints:- http://localhost:5010crankAgent2:jobs:load:endpoints:- http://localhost:5011crankAgent3:jobs:load:endpoints:- http://localhost:5012crankAgent4:jobs:load:endpoints:- http://localhost:5013crankAgent5:jobs:load:endpoints:- http://localhost:5014crankAgent6:jobs:load:endpoints:- http://localhost:5015load.yml 中记录了所有的压测机信息其信息一般不做修改我们可以作为公共的配置来使用无需每个项目都单独维护一份新的3.2.2. 构建压测脚本在这里我们选择wrk2作为本次基准测试工具选择wrk2的原因是支持随机参数可支持设置恒定的吞吐量负载具备wrk的所有功能此时我们针对ProjectA项目新建配置project.profiles.yml作为本次压测的环境配置来使用其配置如下imports:- https://raw.githubusercontent.com/doddgu/crank/sample/samples/wrk2/common/load.profiles.yml # 这边建议使用远程load.profiles.yml地址。(如果输入的是本地路径、则需输入与当前命令所在路径的相对路径)profiles:local: # 本地环境variables:serverAddress: localhost # 应用服务域serverPort: 80 # 应用服务端口connections: 256 # 每个线程处理时保持打开的 HTTP 连接总数 N 连接数/线程数threads: 32 # 线程数warmup: 3 # 预热时间: 3sduration: 180 # 测试时长: 3分钟rate: # 吞吐量参数每秒总请求数project.profiles.yml中记录了指定项目的各环境的配置项目自己独立维护即可除了项目信息、压测机配置之外我们还需要有地方维护我们压测的接口信息这边我的做法是将api独立拆分出来每个yml只配置一个接口的压测信息至于为什么不放到一块而要单独拆分开呢这块考虑到我们压测的最小单元是API接口如果把API接口独立拆分开那么可以对单接口压测而如果我们需要场景压测也可以通过组合接口完成多接口同时压测并且一旦我们完成了某个接口的压测编写后续不需要再改动这个配置如果我们按照场景拆分成不同的yml在yml中再根据定义不同的scenario来做那么后续场景新增加接口还需要再更改这个场景的yml并且scenario中的场景实际上也是根据接口维度区分的目前crank并不能完成单个场景任务同时处理基于以上原因这边我们新调整好的配置格式为新增load.benchmarks.ymlimports:- https://raw.githubusercontent.com/doddgu/crank/sample/src/Microsoft.Crank.Jobs.Wrk2/wrk2.yml- https://raw.githubusercontent.com/doddgu/crank/sample/samples/wrk2/common/project.profiles.ymljobs:server:source:repository: https://github.com/doddgu/crankbranchOrCommit: sampleproject: samples/hello/hello.csprojreadyStateText: Application started.scenarios:api:application: # 实际压测项目时可移除此节点此处是为模拟应用服务启动job: servervariables:duration: 1load:job: wrk2variables:serverPath: /user/getscript: request.luaduration: 1profiles:defaultParamLocal: # 本地环境的参数信息variables: serverQueryString: ?id{1}serverQueryParameter: 1||2 # 随机请求/get?id1、/get?id2按照此格式保存后续新增接口也可以快速复制简单修改即可快速完成压测工作的编写这样一来如果我们希望对localhost:5000/user/get这个接口做压测仅需要在crank控制端输入crank --config load.benchmarks.yml --scenario api --load.framework net5.0 --application.framework net5.0 --profile local --profile crankAgent1 --description 获取用户详情 --profile defaultParamLocal3.2.3. 构建批处理命令但作为一个开发人员总是希望事情能更简单一点每次输入命令太麻烦了所以就想到了通过批处理快速完成任务的发送最终的项目结构就变成了benchmarks
├─ defaultTitle 接口名称( Description )
└─ load.bat 最终执行的脚本其中指定了要指定的yml配置、场景、以及任务环境是.net 5.0
└─ load.benchmarks.yml yml配置
└─ load.local.bat 测试本地环境时要执行的脚本、格式load.{环境}.bat
└─ README.md 帮助文档每次通过双击load.{环境}.bat就完成了对当前接口的压力测试然后就是等待结果输出……| application | |
| --------------------- | -------------- |
| CPU Usage (%) | 1 |
| Cores usage (%) | 10 |
| Working Set (MB) | 85 |
| Private Memory (MB) | 278 |
| Build Time (ms) | 3,469 |
| Start Time (ms) | 352 |
| Published Size (KB) | 93,323 |
| .NET Core SDK Version | 5.0.404 |
| ASP.NET Core Version | 5.0.1355738ff |
| .NET Runtime Version | 5.0.13b3afe99 || load | |
| --------------------- | -------------- |
| Build Time (ms) | 3,281 |
| Start Time (ms) | 0 |
| Published Size (KB) | 74,276 |
| .NET Core SDK Version | 5.0.404 |
| ASP.NET Core Version | 5.0.1355738ff |
| .NET Runtime Version | 5.0.13b3afe99 |
| First Request (ms) | 86 |
| Requests/sec | 2 |
| Requests | 2 |
| Mean latency (ms) | 2.68 |
| Max latency (ms) | 2.68 |
| Bad responses | 0 |
| Socket errors | 0 |
| Latency 50th (ms) | 2.68 |
| Latency 75th (ms) | 2.68 |
| Latency 90th (ms) | 2.68 |
| Latency 99th (ms) | 2.68 |
| Latency 99.9th (ms) | 2.68 |
| Latency 99.99th (ms) | 2.68 |
| Latency 99.999th (ms) | 2.68 |3.2.4. 构建场景压测批处理命令通过上面的一番操作我们已经可以很容易的对单接口进行压测但目前想模拟完成多接口同时压测还需要再改造一下之前我们想到crank目前只能完成单独压测任务那是不是有多个Agent每个Agent单独压测一个接口并同时启动多个Agent同时压测是不是可以模拟出来场景压测那我通过批处理任务多点几次不同的接口压测不就可以了基于以上考虑又做了一个批处理脚本用于调用多个接口的压测任务启动最后的结构如下所示Crank
├─ benchmarks 压测脚本
│ ├─ api 接口压测脚本
│ │ ├─ add
│ │ └─ get
│ ├─ scipts lua脚本
│ │ ├─ common lua公共脚本
│ │ │ ├─ oauth.lua 认证lua脚本
│ │ │ ├─ util.lua lua工具类脚本
│ │ ├─ request.lua 封装请求lua脚本
│ ├─ scripts.tar lua脚本压缩包
├─ common
│ ├─ load.profiles.yml agent 负载机配置
│ ├─ project.profiles.yml 项目配置
│ ├─ scripts.profiles crank 执行script配置用于对输出结果的二次处理
│ ├─ project.profiles.yml 项目配置
├─ scripts 场景压测脚本
│ ├─ 用户.bat 用户压测
└─ env 环境配置标记当前需要压测的环境在哪个配置文件中存储
└─ env.local 本地环境存储本地环境的配置信息
└─ README.md 帮助文档4. 结尾通过上面的操作我们已经完成了对单接口以及单场景的压测通过控制台可以清晰的看到每个接口的压测结果我们只需要耐心等待压测任务结束并整理压测结果数据最后进行汇总我们的任务就完成了但压测结果的收集也是一个费事费力的工作作为一个开发是不想把时间花费到这些整理表格的事情上那我们如何做可以把整理表格数据的工作节省下来让我们可以歇会儿呢……源码地址https://github.com/doddgu/crank/tree/sample/samples/wrk2参考链接https://www.cnblogs.com/xinzhao/p/6233009.html开源地址MASA.BuildingBlockshttps://github.com/masastack/MASA.BuildingBlocksMASA.Contribhttps://github.com/masastack/MASA.ContribMASA.Utilshttps://github.com/masastack/MASA.UtilsMASA.EShophttps://github.com/masalabs/MASA.EShopMASA.Blazorhttps://github.com/BlazorComponent/MASA.Blazor如果你对我们的 MASA Framework 感兴趣无论是代码贡献、使用、提 Issue欢迎联系我们
