百度压测，分析性能拐点

朱雀 2023-06-05 08:56 204阅读 0赞

## 概述 ##

空闲之余用jmeter对百度进行了一次压测，目的是分析一下性能的拐点，验证一下理论知识

## 操作  ##

### 第一次实验：200并发 ###

并发200，不限迭代次数，同时在请求下面加RPS定时器。

目的是在200线程下，将RPS逐步增加到**1000/S**,并持续运行一段时间。

![946454-20190804083253280-126377897.png][]

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

![946454-20190804081946581-164627728.png][]

**启动jmeter，运行一段时间之后我们观察一下监听器的数据图表。**

**RPS 在793/s的时候，出现拐点，请求曲线的角度开始收窄**

![946454-20190804083532714-1365813422.png][]

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

![946454-20190804084525481-933083713.png][]

**另外，在1:03秒的时候，也就是TPS达到 907/S 的时候，事物开始出现错误。此时短暂出现百度页面打不开的情况。**

**1：可以认为此处就是一个性能瓶颈**

**2：有可能是百度对ip的访问量做了限流，防止爬虫**

**3：有可能是我当前环境的问题，包括带宽，内存，cpu等等资源的限制，后期都需要考虑进去**

### 观察分析聚合报告 ###

![946454-20190804085620525-2130071609.png][]

**在性能稳定的情况下，才可以套用公式去计算出最大并发数**

**1：稳定状态下，最大 RPS= 793/S**

**2：稳定情况下，响应时间大约长期保持在 160 ms**

**3：稳定情况下，峰值并发数大约是 793\*160=126**

**4：稳定情况下，****峰值并发=平均并发 + 3\*√平均并发，所以得出平均并发大约是 96 **

### 第二次实验：**100并发** ###

这一次我们把线程数收紧，只给100并发。以此观察线程数降低的情况下，压力会不会变小

**观察到，请求数依然在790-800这个区间变缓**

![946454-20190804091503589-1696774906.png][]

![946454-20190804092043638-990364363.png][]

## 结论 ##

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

** 未完待续。。。。**

转载于:https://www.cnblogs.com/Zfc-Cjk/p/11297219.html

[946454-20190804083253280-126377897.png]: /images/20230601/9fe0470c346640ffbda05d77fba2a16c.png
[946454-20190804081946581-164627728.png]: /images/20230601/f54fbf214ad14ccf8e0749659f34170d.png
[946454-20190804083532714-1365813422.png]: /images/20230601/13323151be554db9a10ed89dec539532.png
[946454-20190804084525481-933083713.png]: /images/20230601/db617850ffb040f190ab0a6516b31a75.png
[946454-20190804085620525-2130071609.png]: /images/20230601/80d7265166614c8093c3e9e4e7447fa2.png
[946454-20190804091503589-1696774906.png]: /images/20230601/8fc428a11197472984fb33b4d5f01543.png
[946454-20190804092043638-990364363.png]: /images/20230601/52f546bdd832444595434457dd3f8dc4.png