如何进行性能测试（在百度工作时日常压测总结）

原创已于 2022-02-13 18:17:56 修改 · 置顶 · 6.2k 阅读

45 ·

CC 4.0 BY-SA版权

文章标签：

#压力测试

于 2021-04-04 21:48:30 首次发布

接口测试同时被 2 个专栏收录

6 篇文章

订阅专栏

性能压测

3 篇文章

订阅专栏

本文详细介绍了性能测试的过程，包括压测目的、场景、步骤和评估标准。通过设定目标QPS，检查服务器资源，分析响应时间和TPS，来识别系统瓶颈。当遇到问题时，会从代码优化、资源分配、数据库性能等方面进行排查。90%和95%的响应时间阈值是基于用户体验设定的。此外，还讨论了服务资源与响应时间的关系，以及如何定位性能问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

如何做性能测试

背景

性能压测通常是对新接口、已有的常用接口或一个比较重要的新接口进行压测，目的是为了找出平时业务流量压力的峰值QPS时，所需的后台资源，或找出该线上配置时最大能承受的QPS。

场景

一、知道目标qps，看服务器需要多大的资源
步骤：

将线下配置与线上配置保持一致；
编写压测方案（包括背景、接口信息、压测场景、压测前准备、压测记录、压测结果分析）；
编写压测脚本-设置jmeter参数【线程数、常数吞吐量计时器、header、http请求、响应断言、聚合报告】开始运行；
查看聚合报告，看错误率，90、95的响应时间，吞吐量；
不通过，则进行排查问题：【1.查看cpu、内存是否达到瓶颈；2.查看数据库连接数、cpu、内存等是否达到瓶颈；3.或配合rd，通过trace组件来排查耗时较高的方法，以进行优化；】；
经过优化或对服务资源调整，使达到压测通过标准【错误率为0的情况下，90或95的响应时间小于**ms】；
编写压测报告，进行风险分析；

二、不知道目标qps，需要进行一个容量探底压测

线下与线上资源保持一致；
先预估一个最大qps，查看聚合【错误率、90和95的响应时间、TPS】、查看服务器的cpu、内存，来判断是否达到压测通过标准；
不通过，降低压测的qps，直到满足压测通过标准。
逐步调整qps，当达到某项满足压测用过标准的临界值时，此时qps就是能承受的最大qps
（或通过阶梯压测的方法来确定）

压测的线性关系

一、没达到瓶颈
随着压力的增大：
1.平均响应时间变化不明显
2.tps增大
二、达到瓶颈
随着压力的增大：
1.平均响应时间成比例增大
2.tps不变

影响压测的因素（找瓶颈及优化）

1.代码优化，逻辑优化，加缓存优化
2.pod的cpu、内存、磁盘IO读写
3.网络消耗
4.数据库的cpu、内存、连接数等等

问题

1.通过什么来规定出压测通过的qps值？
答：根据平时业务流量压力（举例说明）。
2.为什么规定百分之90、95的响应时间小于500ms（类似）？
答：这根据平时用户的使用习惯，例如我们公司通常要求小于700ms，但是具体多少项目组根据实际情况商量后定，具体写在需求文档中。
3.怎么看服务器的cpu、内存？
答：我们公司有自己的服务监控平台，以图表的发方式展示出cpu、内存等变化
4.如果发压足够，但是服务器的cpu、内存就是上不来，原因会在哪里？
答：可能是数据库连接数设置过小。
5.如果90或95的用户响应时间超过了规定值，那么你怎么定位问题出在哪里？
答：先看服务器的cpu、内存是否打满，如果打满说明服务器的资源达到了瓶颈，如果服务器的cpu、内存没达到瓶颈，那么看数据库的cpu、内存、连接数是否打满，如果打满，说明数控资源达到瓶颈，最后配合rd进行优化，例如通过trace来排查耗时或cpu最长的方法，如果实在没有优化的空间，那么就最后进行服务的扩容或扩大资源配置。
也有可能是IO瓶颈、网速、进程线程数配置较少占用完全、kafka等队列积压消费线程不够（kafka积压解决：增加机器配置，增加分区，增加消费者线程）等
6.服务的pod越多，响应时间就会越短吗？
答：如果压测没有达到瓶颈，增加pod数响应时间变化不明显；如果已经达到压测瓶颈，那么增加pod数，响应时间就会缩短。
（继续补充中。。。）