【Jmeter】api性能测试总结
2021-07-02 07:07
标签:机器 大于 线程 average media 分享 右上角 9.png 设计 平时常用的性能测试:api性能测试+场景性能测试;今天就说一说api性能测试 需求:对某api进行性能测试,看看最大承受的并发数,分析下图表 分析: 错误思路:当我们接到这个需求的时候,很多人不管三七二十一,先把接口写起来,然后给他个1000个并发,压倒报错为止,但是实际上你知道怎么去压测么,怎么分析TPS么?怎么找到最大并发数?怎么分析报错请求?那我们到底怎么分析呢 分析思路: 在我们实战前,先了解一下性能指标: 通常情况下,一般我们可能不会添加其他插件的前提下,都会添加一个监听器->聚合报告,那么聚合报告到底用来做什么的呢? 我们可以看见:average(平均响应时间) median,90% 95% min (最小) ,max(最大) 都是跟时间有关系,所以我们可以侧面理解为,聚合报告,大部分就是监控整个访问时间 其他: sampler:一共完成了多少请求 Throughput:吞吐量,默认情况下标识每秒处理的请求书,可以指服务器处理能力,tps越高说明服务器处理能力越好 场景1:并发20个用户,每秒增加2个用户,请求2000次, 线程组:相当于并发多少用户 Ramp-UP: 每秒增加2个用户, 20/2=10 ,所以填10,意思是1秒内往上加2个用户 循环:请求2000次;计算:20000/线程组(20)= 100 分析一波: 首先右上角:3/20 : 当前线程往上加,最大并发数是20,3是当前线程数 看下报告: 1.sampler:当前一共2000个请求 2吞吐量远远大于20个线程组数,tps很高,说明服务器完全能承受; 场景:并发200个用户,每秒增加20个用户,请求20000次 分析: 1.首先错误率很高,就能看出很多了 2.吞吐量小于当前并发数,说明200个并发数不适合,已经不能够承受了 3.为了找到最合适的并发数。可以设计不同场景,例如用二分法,100个并发用户,150个并发用户之类, 其实性能测试远远不止于这些,但是从基础的吞吐量,以及并发数,我们就可以分析很多问题了,如果设计服务器上监控,那么又是一个概念了。我觉得从这篇文章至少我们可以坚持api性能的最合理的并发数,以及tps. tps越高说明性能越好。若压测的机器性能很好,出现吞吐量小于并发数,说明并发数不能再增加了,可以慢慢减下来,找到合理并发数 ps: 有错误欢迎指出来,虚心请教。 【Jmeter】api性能测试总结 标签:机器 大于 线程 average media 分享 右上角 9.png 设计 原文地址:https://www.cnblogs.com/totoro-cat/p/9936598.html1.前提概念
2.如何进行性能测试?
3.性能指标
4.实战
1.准备脚本
2.脚本分析
3.场景二脚本分析:
5.总结
文章标题:【Jmeter】api性能测试总结
文章链接:http://soscw.com/index.php/essay/100686.html