概述
空闲之余用 jmeter 对百度进行了一次压测, 目的是分析一下性能的拐点, 验证一下理论知识
操作
第一次实验: 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
2: 稳定情况下, 响应时间大约长期保持在 160 ms
3: 稳定情况下, 峰值并发数大约是 793*160=126
4: 稳定情况下, 峰值并发 = 平均并发 + 3*√平均并发, 所以得出平均并发大约是 96
第二次实验: 100 并发
这一次我们把线程数收紧, 只给 100 并发. 以此观察线程数降低的情况下, 压力会不会变小
观察到, 请求数依然在 790-800 这个区间变缓
结论
此当前环境下, 不论是本机资源, 还是百度设置了限流等原因, 我们的最大请求数只能维持在 790-800, 最大 TPS 维持在 700-730 之间, 最大并发数在 130 左右. 超出这个范围就开始出现波动
未完待续....
来源: https://www.cnblogs.com/Zfc-Cjk/p/11297219.html