性能测试连载 (9)-压测实战分析性能拐点

咨询微信:uhz2008

概述

本文对百度进行一次实战压测,验证一下理论知识,分析一下性能拐点

操作

第一次实验:200并发

并发200,不限迭代次数,同时在请求下面加RPS定时器。目的是在200线程下,将RPS逐步增加到1000/S,并持续运行一段时间
性能测试连载 (9)-压测实战分析性能拐点_第1张图片
在线程下面添加TPS,HPS,响应时间三种监听器
性能测试连载 (9)-压测实战分析性能拐点_第2张图片
启动jmeter,运行一段时间之后我们观察一下监听器的数据图表
RPS 在793/s的时候,出现拐点,请求曲线的角度开始收窄
性能测试连载 (9)-压测实战分析性能拐点_第3张图片
TPS在 720/s左右开始出现剧波动,前期一直保持平稳上升,可以认为这是吞吐量的一个拐点
性能测试连载 (9)-压测实战分析性能拐点_第4张图片
在1:03秒的时候,也就是TPS达到 907/S 的时候,事物开始出现错误。此时短暂出现百度页面打不开的情况
1:此处可能就是一个性能瓶颈
2:有可能是百度对ip的访问量做了限流,防止爬虫
3:有可能是我当前环境的问题,包括带宽,内存,cpu等等资源的限制,后期都需要考虑进去

观察分析聚合报告
性能测试连载 (9)-压测实战分析性能拐点_第5张图片
在性能稳定的情况下,可以套用公式去计算出最大并发数
1:稳定状态下,最大 RPS= 793/S。这个值可以理解为最大支持1秒内793个用户同时去访问百度。当然这种说法不太客观,更大的可能是百度对同一个IP在同一时间的访问数做了限制
2:稳定情况下,响应时间大约长期保持在 160 ms
3:稳定情况下,峰值系统并发数大约是 793*160=126。这个值可以理解为只要启动126个线程就可以在一秒内满足793/s的压力值。或者换个角度,也可以表示最大支持126个用户在1s内不停的访问,一直达到瓶颈点(只要你手速够快)

第二次实验:100并发
这一次我们把线程数收紧,只给100线程。以此观察线程数降低的情况下,压力会不会变小
观察到,请求数依然在790-800这个区间变缓
性能测试连载 (9)-压测实战分析性能拐点_第6张图片
性能测试连载 (9)-压测实战分析性能拐点_第7张图片
结论
此当前环境下,不论是本机资源,还是百度设置了限流等原因,我们的最大请求数只能维持在790-800,最大TPS维持在700-730之间,最大系统并发数在130左右。超出这个范围就开始出现波动

你可能感兴趣的:(性能测试,jmeter)