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

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.Contrib：https://github.com/masastack/...

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

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

MASA.Blazor：https://github.com/BlazorComp...

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