如何做压测？

阿里妹导读：压测的一般流程和方法是什么？需要关注哪些数据指标？如何推算后端需要支持的qps？本文分享总结压测过程中需要注意的问题，希望对同学们有所启发，欢迎讨论~

文末福利：云服务器超值优惠。

一  压测目标

在开始做压测计划之前，一定要先明确压测的目标是什么，虽然最终的目标肯定都是优化系统的性能，但是不同的出发点，可能需要采取不同的方法。

一般来说，可能有以下一些目的：

1  挖掘系统瓶颈点，优化系统性能

尤其对新系统上线，缺乏性能基线数据，此时压测一般没有明确的qps/rt等指标，而是通过不断施压，不断逼近系统的极限，从而暴露问题，修复问题。

2  建立性能基线

主要是为了收集系统当前的最大性能指标，一般会根据业务特点，先确定对rt和错误率的容忍度，然后通过压测推算出能够支持的最大qps, 并发量等。

同时可以结合性能指标和监控数据，来建立合理的预警机制，设立系统水位报警项，限流阈值，弹性策略等。

量化系统能力/SLA等 （比如在竞标中引用）。

3  性能回归

对于已上线系统，或者性能需求明确的系统，可以根据线上实际的运行情况，确定系统需要支撑的qps/rt, 然后在涉及性能影响前做回归校验，确保性能满足预期。

4  系统稳定性

更侧重在一定压力的情况下，系统是否能长时间稳定持续的提供SLA保障。

一般可以考虑将压力设定到业务峰值的80%，持续施压。

5  网络/线路延迟稳定性等

在一些特殊的业务场合，对延迟的容忍度极小，比如DNS解析，CDN服务，多人实时在线游戏，高频交易等等，需要网络质量，尤其是不同线路（电信/联通/教育网/...）间的差异。

二  压测对象

明确了压测目标后 ，就是确定要压什么，来实现目标。

一般来说，压测对象可以这么分：

• 后端

• 单api

• 单业务逻辑场景

• 前端

• 单request

• 单操作

• 单页

• 整体页面平均情况

三  压测数据

压测过程中，一般主要关注一下数据指标：

1  starter/client

最重要的三个指标：

• qps

• rt

• 成功率

其他的：

• 页面平均响应时间 （重要）。

• 并发量（其实没那么重要，主要还是qps）。

• 最大用户同时在线数 （用户登录系统，一般不需要额外压测，除非业务场景特殊）。

• 网络质量（延迟，波动等，不展开）。

2  server

主要是监控数据：

• cpu usage

• load

• mem

• jvm/fullGC

• 连接数(netstat)

• disk io (iostat / iotop)

四  压测结果分析

一般是随着压力的增加（并发请求的增加）探究qps/rt/成功率三者的关系，从而找到系统的平衡点，如果能结合服务端的监控数据，就更好。

五  压测工具

1  jmeter

concurrent Thread Group

java sampler

composite chart

可以将多个chart组合到一个chart中，并且坐标系会自动伸缩，方便在一个图中展示结果。

六  性能指标推算方法

以上都是一些系统向的指标数据，其实对用户来说是不感知，或者说也是没有意义的。那什么样的数字是有意义的呢？举个例子：

• 如果你提供的是一个在线的网页服务，那用户可能关心的是，你的系统在保证不察觉卡顿的情况下（系统的SLA， 实际可能容忍存在偶发的页面错误重试）能承受多少人并发使用。

• 如果你提供的是个结算系统，那用户可能关心的是，在保证交易有效性的情况下（不能出错，但是可以偶发超时重试，同样是系统的SLA），每秒可以处理多少笔订单。

举例分析：

1  基本算法

此处pv表意不清，实为后端日志统计的后端api的调用次数，如果有前端统计的一般意义上的pv(page visit)，基本原理相同，可以简单换算一下，pv * x-ratio = 后端调用次数。

1.  获取现场每日asapi PV/UV的均值/峰值。

2.  取Max（PV峰值*0.8，每日PV均值）作为目标PV'， PV'时段的UV值作为实际并发用户参考值N'， 计算PV'/perMinute/N'作为每分钟用户操作触发api次数O'。

3.  根据以下规则换算成后端需要支持的qps：

• 3.1  模型假设：2/8原则——每日有80%的PV发生在20%的工作时间内（ratio=0.8）。

• 3.2  假设页面单个请求映射到后端api请求比例为1:10，假设一天working hour为8小时 (e=10)。

• 3.3  假设一般用户，高峰期每分钟操作页面10次 （o=10）。

• 3.4  根据现场日PV计算支持N'用户并发操作需要的qps：PV' * ratio/(working hour∗60∗60∗(1−ratio) )= qps‍

• 3.5  根据现场峰值小时级PV计算支持N'用户并发操作需要的qps：PV' * ratio/(1∗60∗60∗(1−ratio) ) = qps

4.  根据压测qps推算能够支持的最大用户同时使用数：

• 4.1  同样基于上述公式，根据上述假设，1分钟内，每个用户操作10次，每次前端操作对应后端10个api：

• 1分钟PV = N * 10 *10

• N *10 *10 / 60 = qps ==> N = qps * 0.6

• 4.2  如果按照小时为单位推算，1个小时内，每个用户操作页面100次，每次前端操作对应后端10个api：

• 60分钟PV = N * 100 *10

• N *100 *10 / 60*60 = qps ==> N = qps * 3.6

2  正向推演

如果现场环境数据表明，高峰期9:00~10:00有50人登录过系统，pv累计10000，那么根据（3.1），系统整体qps >= 11+ 才能维持当前用户量正常使用。

3  反向推演

如果家里环境压测结果表明，随机API调用qps=30， 保持上述假设，参照（4.2），即可支撑18人高峰期同时操作。

4  不严谨的地方

上述算法针对随机API按照1:1计算，实际上调用肯定是不均匀的，可以根据现场的数据统计下api的调用分布，压测是模拟相同的调用分布尽量贴近实际。

另外用户每分钟操作页面次数，和每次前端请求对应后端api的膨胀比都是预估出来的，虽然可以根据模型做近似，但是不如直接根据现场数据计算出来准确。

七  其他考量

• 链路跟踪能力，分析瓶颈点

• api log

• eagleye-traceId

• 缓存对数据库的影响

• 是否需要压到db层，要考虑压测场景。

• 是否需要创造海量的随机压测数据 （比如针对单用户的缓存优化场景，单一用户的性能不能用来推送多用户并发的场景）。

• 同步接口异步接口的压测 （staragent）

• 主要考验后台任务处理能力（异步任务提交即时返回了）。

• 系统不同层次的限流设置对API的影响

• 比如有业务层的限流如Sentinel, Nginx层的限流如X5, 或者其他基于LVS的限流等。

• 消息通信，尤其是广播消息。

• 数据库，尤其是写一致性。

• 复杂场景的长链路调用。

• Nginx/Tomcat的配置对请求的影响。

• 容易忽视的对象序列化/反序列化对性能的影响。

• 热点数据。

---

云服务器超值优惠

低至1元起

阿里云开发者成长计划面向全年龄段开发者，依托免费资源、免费体验、免费学习、免费实践4大场景，全面助力开发者轻松掌握云上技能。现推出开发者专属的特价云服务器，涵盖轻量应用服务器、云数据库MySQL、实时计算Flink等多个爆款，低至1元起！

识别下方二维码，或点击 “阅读原文” ，快去优惠购买吧~

戳我，优惠购买。