测试驿栈-由浅入深学性能 性能测试连载 (9)-压测实战分析性能拐点

飞天小子的性能课堂 · 2019年10月11日 · 最后由 咖啡咖 回复于 2021年04月01日 · 1875 次阅读

性能答疑 QQ 群:697244251

概述

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

操作 

第一次实验:200 并发

并发 200,不限迭代次数,同时在请求下面加 RPS 定时器。目的是在 200 线程下,将 RPS 逐步增加到 1000/S,并持续运行一段时间

 
在线程下面添加 TPS,HPS,响应时间三种监听器
 

 
启动 jmeter,运行一段时间之后我们观察一下监听器的数据图表
RPS 在 793/s 的时候,出现拐点,请求曲线的角度开始收窄

 
TPS 在 720/s 左右开始出现剧波动,前期一直保持平稳上升,可以认为这是吞吐量的一个拐点

 
在 1:03 秒的时候,也就是 TPS 达到 907/S 的时候,事物开始出现错误。此时短暂出现百度页面打不开的情况
1:此处可能就是一个性能瓶颈
2:有可能是百度对 ip 的访问量做了限流,防止爬虫
3:有可能是我当前环境的问题,包括带宽,内存,cpu 等等资源的限制,后期都需要考虑进去
 
观察分析聚合报告

 
在性能稳定的情况下,可以套用公式去计算出最大并发数
1:稳定状态下,最大 RPS= 793/S。这个值可以理解为最大支持 1 秒内 793 个用户同时去访问百度。当然这种说法不太客观,更大的可能是百度对同一个 IP 在同一时间的访问数做了限制
2:稳定情况下,响应时间大约长期保持在 160 ms
3:稳定情况下,峰值系统并发数大约是 793*160=126。这个值可以理解为只要启动 126 个线程就可以在一秒内满足 793/s 的压力值。或者换个角度,也可以表示最大支持 126 个用户在 1s 内不停的访问,一直达到瓶颈点(只要你手速够快)
 
第二次实验:100 并发
这一次我们把线程数收紧,只给 100 线程。以此观察线程数降低的情况下,压力会不会变小
观察到,请求数依然在 790-800 这个区间变缓

结论
此当前环境下,不论是本机资源,还是百度设置了限流等原因,我们的最大请求数只能维持在 790-800,最大 TPS 维持在 700-730 之间,最大系统并发数在 130 左右。超出这个范围就开始出现波动

性能测试全系列博客
jmeter 接口自动化系列博客
jmeter 基础内容在线公开课
jmeter 性能测试在线公开课
接口自动化课程
性能测试课程

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 5 条回复 时间 点赞

上面截图拐点后面有很多较大波动,波动原因有哪些?

gc 过快,上下文切换过于频繁,IOWAIT 过长

我认为第一次实验结论第三点完全没有必要。并发线程数只是压力工具用来施压的一个策略,不能用来衡量系统支持的并发能力。tps 才是可以真正可以反应系统支持的并发能力。还有就是群主不要把 rps 以及 tps 做为两个概念,其实他们按理说是一致的没有区别,都是反应服务器在一段时间可以处理的多少事物。并且你分析的拐点我也不太认可,你第一次 10 秒内 rps 增加到 100,tps 也是在 10s 增加到了 100,但第二次是在 20 秒内直接增加到了 400,但是你看 20 秒的 tps 确实在连 300 都不到。这个时候性能已经开始衰减了吧。

old shen 回复

1:第一点我写的确实有点多余了。但是压力有两种模式:一种是从客户端角度衡量的用户并发模式,第二种是服务端角度衡量的吞吐量模式
2:rps 是客户端每秒发起的请求,tps 是服务端每秒完成的请求。实际情况中,tps 往往和 rps 不等,因为要考虑到中间的网络和服务处理时间。如果 tps=rps,那么 latency 只能等于 0
3:10s 内达到 100,再花 20s 达到 400。实际就是 30s 内达到 400

5楼 已删除

793*160=126 这个公式 是个什么鬼

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册