标签：RPS 793 连载 压测 性能 并发 线程 TPS 百度
概述
本文对百度进行一次实战压测，验证一下理论知识，分析一下性能拐点
操作
第一次实验：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左右。超出这个范围就开始出现波动
测试驿栈-飞天小子
发布了9 篇原创文章 · 获赞 0 · 访问量 293
私信
关注
标签：RPS,793,连载,压测,性能,并发,线程,TPS,百度 来源： https://blog.csdn.net/ufuhz2008/article/details/104123479
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。