7. 堪比JMeter的.Net压测工具 - Crank 总结篇 - crank带来了什么

测试技术 创建于:2023-05-27

1. 前言

通过上面的学习,我们已经了解清楚crank的职责以及作用,那么我们重新回来思考一下,crank能为我们带来什么?

2. Crank带来了什么?

  • 为分布式压测提供了解决方案、可以模拟更高强度的压测
    • 单机压测最多提供65535,通过支持多个Agent可以很轻松的突破这个极限
  • 提供了压测结果二次处理的能力,并支持将结果保存到json、csv、数据库甚至是es(目前仍在对接)
    • 通过对以往压测数据的结果做折线图的展示
    • 通过ci可以完成自动化触发压测,再通过折线图清晰了解每次代码对性能的提升情况

3. Crank还能更进一步吗?

上面的实战训练我们仅仅是做了基础的工作,尽管我们通过模拟多接口同时压测完成了对单场景的压测,但真实的项目远远不会是所有人都同时访问一个页面,而不访问其它页面,那我们如何模拟出更贴近真实场景的用户轨迹呢?

真实的用户场景应该更像

用户行为

如果我们希望更进一步,想知道我们的系统的极限究竟在哪里,我们可以按照按照此用户场景进行深度还原压测场景,完成对整个场景的压测,并通过调整副本、带宽、Redis集群、数据库集群数量等方式提升QPS,最后通过不断的压测以及配置不断的增加,了解到我们使用什么样的配置、用多少副本、用多少带宽、什么样的Redis、数据库集群能够抗住多少的用户,但这个需要视我们真实的业务场景,如果QPS到100就够用的话,那么我们花费那么高的成本搞那么大的QPS有什么意义呢?我们又不是需要再做一个淘宝出来,实际没有那么高的用户量,搞到极致的优化也只是劳民伤财罢了

4. 疑问

  • Agent的压测机配置必须很高吗?
    • 压测机的配置高,将赋予压测机更高的压测能力,但QPS的高低并不是通过压测机来决定,Qps低的项目,搞个超级计算机过来,Qps仍然低
  • 为何我启动Agent执行任务后每次都需要Install Sdk?每次安装都需要半天,翻墙我也处理过了,但还是很慢
    • 建议Agent启动时指定dotnethome,并且在启动任务时,最好指定任务的框架环境是已经存在的环境,Agent的启动配置可以查看入门篇,指定任务运行框架可以查看进阶篇
  • 为何我通过crank官方的命名运行出错呢?
    • crank还在持续更新升级中,可能会出现用新版本的crank发送上文示例不能使用的情况,可以安装指定版本的crank,以上示例都有在0.2.0-alpha.21567.1版本运行成功
  • 我想自己搭建Agent的docker镜像,文中提供的镜像不知道是否安全?
    • 文中用到的镜像是通过下面的dockerfile编译的,没有搞很复杂的东西,不放心的可以使用自建镜像
    • doddgu/crankagent:net5.0是.net 5.0版本
  • 我的压测场景也需要登录,但不需要实现每次请求都是一个新的用户,我该选择bombardier还是wrk、wrk2呢?
    • 针对压测场景简单的,又不需要实现多用户、不需要动态参数的可以用bombardier、简单不需要学习lua、成本低
    • 希望可以用动态参数,玩一些复杂场景的,选择wrk或者wrk2更合适
  • 压测场景单一,且不需要实现多用户、不需要动态参数不能使用wrk、wrk2吗?
    • bombardier能实现的场景,wrk、wrk2都可以做到
    • 针对简单的get请求,不需要更改参数使用wrk一样很简单、使用post请求的需要多掌握一点lua脚本知识,有条件的还是建议使用wrk、wrk2,它更灵活入手成本也不是太大

crank agent dockerfile

FROM mcr.microsoft.com/dotnet/sdk:5.0

ENV PATH="${PATH}:/root/.dotnet/tools"

EXPOSE 5010

RUN dotnet tool install -g Microsoft.Crank.Agent --version "0.2.0-alpha.21567.1" 

ENTRYPOINT crank-agent --dotnethome "/usr/share/dotnet"

5. 总结

Crank的功能其实是很单一的,它不像我们起初想象的那样庞大,所有的事情都能做,也没那么复杂,但我们也可以说Crank什么都能干,因为它提供了让我们运行dotnet项目以及在docker中运行dotnet程序的能力。

但它最后能做什么事取决于使用它的人想用它来干什么,它只是一个工具而已,不要把它想得太美好,有了它以后可以不写代码,自动化完成测试工作,我只需要等结果,自动出报告等等……有这样想法的还是去洗洗脸吧,大白天的竟然在做梦?

压测以及性能调优考验的是我们对整个系统的一个全局掌控能力,通过压测让我们知道目前系统的瓶颈在哪里?等我们的业务规模到了瓶颈时,可以通过调优提高项目的QPS、使其响应能力更快,不会因为系统而影响我们的业务,其目的是帮助业务发展的更好,但如果业务没发展起来,一味的陷入性能调优这个深坑中去,会使得我们花费高昂的代价做了没有实际意义的事,就比如说家里总共就四口人,非得搞个中巴,美其名曰可以拉更多的人,过年走亲戚不会坐不下什么的,每次出门费油又心疼的不得了,最后舍不得开了,最后还得花钱给它找停车位,那就得不偿失了

开源地址

MASA.BuildingBlocks:https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib:https://github.com/masastack/MASA.Contrib

MASA.Utils:https://github.com/masastack/MASA.Utils

MASA.EShop:https://github.com/masalabs/MASA.EShop

MASA.Blazor:https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣,无论是代码贡献、使用、提 Issue,欢迎联系我们

16373211753064.png

原文地址:https://my.oschina.net/u/5447363/blog/5517779

免责声明:本文来源于互联网,版权归合法拥有者所有,如有侵权请公众号联系管理员

* 本站提供的一些文章、资料是供学习研究之用,如用于商业用途,请购买正版。

MASA技术团队