如何做压测?-阿里云开发者社区

开发者社区> 阿里技术> 正文

如何做压测?

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

image.png

一 压测目标

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

一般来说,可能有以下一些目的:

image.png

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

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

2 建立性能基线

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

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

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

3 性能回归

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

4 系统稳定性

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

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

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

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

二 压测对象

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

一般来说,压测对象可以这么分:

image.png

  • 后端
    • 单api
    • 单业务逻辑场景
  • 前端
    • 单request
    • 单操作
    • 单页
    • 整体页面平均情况

三 压测数据

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

1 starter/client

image.png

最重要的三个指标:

  • qps
  • rt
  • 成功率

其他的:

  • 页面平均响应时间 (重要)。
  • 并发量(其实没那么重要,主要还是qps)。
  • 最大用户同时在线数 (用户登录系统,一般不需要额外压测,除非业务场景特殊)。
  • 网络质量(延迟,波动等,不展开)。

2 server

主要是监控数据:

image.png

  • cpu usage
  • load
  • mem
  • jvm/fullGC
  • 连接数(netstat)
  • disk io (iostat / iotop)

四 压测结果分析

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

image.png
image.png
image.png

五 压测工具

1 jmeter

concurrent Thread Group

image.png

java sampler

image.png
image.png

composite chart

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

image.png

六 性能指标推算方法

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

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

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

举例分析:

1 基本算法

image.png

此处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
  1. 根据压测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 / 6060 = 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

image.png

  • 缓存对数据库的影响
    • 是否需要压到db层,要考虑压测场景。
    • 是否需要创造海量的随机压测数据 (比如针对单用户的缓存优化场景,单一用户的性能不能用来推送多用户并发的场景)。
  • 同步接口异步接口的压测 (staragent)
    • 主要考验后台任务处理能力(异步任务提交即时返回了)。
  • 系统不同层次的限流设置对API的影响
    • 比如有业务层的限流如Sentinel, Nginx层的限流如X5, 或者其他基于LVS的限流等。
  • 消息通信,尤其是广播消息。
  • 数据库,尤其是写一致性。
  • 复杂场景的长链路调用。
  • Nginx/Tomcat的配置对请求的影响。
  • 容易忽视的对象序列化/反序列化对性能的影响。
  • 热点数据。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

关于阿里的技术创新均呈现于此.

官方博客
官网链接