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

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

https://a.perfma.net/img/2871132
2年前
5024224

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

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

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

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

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

 

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

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

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

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

点赞收藏
分类:标签:
imath60

ASAP

请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
24
2