性能文章>【2】性能测试平台从设计到实现-中控系统之资源管理>

【2】性能测试平台从设计到实现-中控系统之资源管理原创

https://a.perfma.net/img/2871132
6月前
3304021

        本着由浅入深,层层递进的讲述方式,先把平台的大致轮廓以更加感官的方式呈现给的各位同学。我们今天来聊一聊资源管理。在最初的设计中,任务以pipeline+duty的方式串联起各个可复用的资源【包括但不限于计划、用例、数据、压力模型、执行节点、监控、通知等】,而在这其中,一个任务必备的四要素是:用例+数据+压力模型+执行节点。其他都是可挂载的非必须要素;

        首先先来看用例,我们的用例提供两种方式,即UI模式和脚本模式,其中UI模式,参考POSTMAN的KV-Editor的交互设计,供用户使用。

        UI用例的优劣势明显,针对简单的单接口压测,同POSTMAN编写接口功能测试一样,几乎没有学习成本,操作简单,便捷。但由于提高了易用性,必然会对功能性做裁剪,所以像场景链路串联、丰富的自定义断言等,我们都没有提供,本着提供20%的功能覆盖80%场景的原则,我们推荐用户在做基本单接口压测时,选择UI用例。

        那如果是复杂的场景串联,设计流量按漏斗比例分配又如何处理呢?脚本是一种不错的选择,由于脚本方式远程支持压测引擎的全部功能,又可以使用第三方库来做响应的补充。堪称完美,对于习惯了写代码做调试的码农,更推荐这种方式。

看完上述的脚本,大家应该能猜到我们的压测引擎选的是什么了吧?后面会有一章来对主流的开源压测引擎做对比介绍,包括JMeter、Gatling、Locust和K6。

 

聊完用例,我们来看看压力模型,并发数和QPS。我们更多用并发数模型来验证秒杀这种瞬时大流量的场景,用QPS来模拟日常流量做系统稳定性的评估。在两大类模型下,我们又可以基于一次性注入、斜率加压、恒定加压、梯度加压来构造我们的自定义压力,根据设置我们来绘制预估压力模型图,便于大家更加直观的验证设置是否符合自己的预期。

压力节点的选择,我们早期是以预先部署的方式,供用户手工选择。这种方式,本质是通过API直连的方式,从中控系统对执行节点下发任务。

最后是数据,我们目前还是以csv类型的测试数据为主,用户手动上传之后即可在用例的Feeder设置中进行使用。

今天先到这里,食堂开饭啦~

分类:标签:
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

借助Xpocket中的perf插件 了解cpu热点函数的抓取原理
本文使用了xpocket工具包的插件链接xpocket地址: [https://plugin.xpocket.perfma.com](https://plugin.xpocket.perfma.com
【0】性能测试平台从设计到实现-开篇
性能测试平台从设计到实现-开篇;从背景介绍、目标价值和特征分析三个方面,对性能测试平台的建设进行阐述
【1】性能测试平台从设计到实现-中控系统
性能测试平台从设计到实现的第二篇,中控系统,本文主要介绍了中控系统的任务管理的新建任务功能,将任务所需的各类资源按照步骤进行拆分,映射到资源管理模块下的各个子模块中,可复用,可新建【支持保存】。任务从创建到实时执行查看到执行完成回看的全过程。
【2】性能测试平台从设计到实现-中控系统之资源管理
性能测试平台从设计到实现的第三篇,中控系统之资源管理,本文主要介绍了资源管理中的四要素,即用例、数据、压力模型和执行节点。
【3】性能测试平台从设计到实现-如何玩转压测脚本
性能测试平台从设计到实现的第四篇,如何玩转压测脚本,本文主要介绍了Gatling引擎的scala脚本的常用写法,直接拿走不用谢~
【4】性能测试平台从设计到实现-玩转压测脚本之场景化压测
性能测试平台从设计到实现的第五篇,玩转压测脚本之场景化压测,本文是第四篇如何玩转脚本的姊妹篇,以春运活动为例,讲解了场景化压测脚本的编写方法
【5】性能测试平台从设计到实现-如何选择适合自己的压力模型
性能测试平台从设计到实现的第六篇,如何选择适合自己的压力模型,本文从实际业务场景出发,介绍两大类场景并发数和QPS下的压力模型构造方法,及在引擎提供的基础能力上,如果简化这部分的工作。
【6】性能测试平台从设计到实现-报告初步解读和平台的增强优化
性能测试平台从设计到实现的第七篇,报告初步解读和平台的增强优化。本文讲述了在压测中和压测结束后,针对报告的解读方法,需关注的指标以及平台所做的增强型优化功能