百度压测，分析性能拐点

概述

空闲之余用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左右。超出这个范围就开始出现波动

 

 未完待续。。。。