百度压测,分析性能拐点

Posted zfc-cjk

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了百度压测,分析性能拐点相关的知识,希望对你有一定的参考价值。

概述

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

操作 

第一次实验:200并发

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

目的是在200线程下,将RPS逐步增加到1200/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左右。超出这个范围就开始出现波动

 

 未完待续。。。。

 

以上是关于百度压测,分析性能拐点的主要内容,如果未能解决你的问题,请参考以下文章

性能分析之压测中 TCP 全连接队列占满问题分析及优化案例

性能分析思路

如何做好性能压测:压测环境的设计和搭建

Loadrunner压测结果性能问题分析指标项

如何做好性能压测的系列讲解

性能分析之长连接全链路压测