百度压测,分析性能拐点

概述

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

 未完待续。。。。

原文地址:https://www.cnblogs.com/Zfc-Cjk/p/11297219.html

时间: 2024-11-08 18:09:40

百度压测,分析性能拐点的相关文章

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

事务分析内容: 用户事务分析是站在用户角度进行的基础性能分析.1.Transation Sunmmary(事务综述)对事务进行综合分析在一定测试时间内用户事务的成功与失败情况,判断系统是否正常运行. 2.Average Transaciton Response Time(事务平均响应时间)测试场景运行期间的事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向. 3.Transactions per Second(每秒通过事务数)在场景运行的每1秒每个事务通过.失败以及停止的数

RocketMQ性能压测分析(转)

原创文章,转载请注明出处:http://jameswxx.iteye.com/blog/2093785 一   机器部署 1.1  机器组成 1台nameserver 1台broker  异步刷盘 2台producer 2台consumer 1.2  硬件配置 CPU  两颗x86_64cpu,每颗cpu12核,共24核 内存 48G 网卡 千兆网卡 磁盘 除broker机器的磁盘是RAID10,共1.1T,其他都是普通磁盘约500G 1.3  部署结构 橙色箭头为数据流向,黑色连接线为网络连接

RocketMQ性能压测分析(转载)

一   机器部署 1.1  机器组成 1台nameserver 1台broker  异步刷盘 2台producer 2台consumer 1.2  硬件配置 CPU  两颗x86_64cpu,每颗cpu12核,共24核 内存 48G 网卡 千兆网卡 磁盘 除broker机器的磁盘是RAID10,共1.1T,其他都是普通磁盘约500G 1.3  部署结构 橙色箭头为数据流向,黑色连接线为网络连接 1.4  内核参数 broker是一个存储型的系统,针对磁盘读写有自己的刷盘策略,大量使用文件内存映射

记5.28大促压测的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下. 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C.UGC.直播等).平台中核心之一的就是订单域相关服务,下单服务.查单服务.支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单.结算.跳支付中心.每次业务方进行大促期间平台都要进行一次常规压测,做到心里

记5.28大促压测的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下. 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C.UGC.直播等).平台中核心之一的就是订单域相关服务,下单服务.查单服务.支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单.结算.跳支付中心.每次业务方进行大促期间平台都要进行一次常规压测,做到心里

Nginx添加Content-MD5头部压测分析

此文转载必须注明原文地址,请尊重作者的劳动成果! 1.1 Webbench是知名的网站压力测试工具,它是由Lionbridge公司(http://www.lionbridge.com)开发.Webbench能测试处在相同硬件上,不同服务的性能以及不同硬件上同一个服务的运行状况.webbench的标准测试可以向我们展示服务器的两项内容:每秒钟相应请求数和每秒钟传输数据量.webbench不但能具有便准静态页面的测试能力,还能对动态页面(ASP,PHP,JAVA,CGI)进 行测试的能力.还有就是他

Jmeter压测与性能监控自动化(二)

基于Jmeter的接口性能测试自动化框架,JMeter+ant+Jenkins主要包括6个部分: 1. 脚本和数据分离实现 jmeter脚本中的服务地址和参数均进行参数化配置,通过配置文件读取,例如dubbo地址变化,直接修改csv配置文件即可 后续考虑将这块做成web页面的,通过web页面上传脚本和配置文件,可设置并发数,压测曲线是梯度还是平行等 2. 批量执行脚本 利用ant批量跑指定目录下的Jmeter脚本,如有新增脚本只要放置在指定目录即可 3. 生成接口运行报告 4. 定位报错接口 5

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句