操作 

第一次实验：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 左右。超出这个范围就开始出现波动

文档都已经上传到飞书知识库，自由阅读