静态健康码打印出来什么样(如何做健康码的性能压测)
静态健康码打印出来什么样(如何做健康码的性能压测)业内常用的压测工具包括 JMeter、Gatling、Locust、k6、Tsung、阿里云 PTS 等。这些工具无一例外,都需要将压测业务的 API,编排为一个压测脚本。构建压测脚本压测的执行环境是一个老生常谈的话题,如果直接在生产环境执行压测,会有2个问题:为了解决这 2 个问题,一般业内采用如下几种方案:以上方案各有优缺点,适用场景也不尽相同,可以根据自己项目所处的阶段灵活选择方案。
为什么要做压测随着无线设备的普及和 5G 的大力建设,越来越多的线上系统、小程序成为了人们生活中必不可少的工具。对于这些工具,都会面对一个问题:系统能承受多少用户同时访问,面对突发的流量洪峰,能否保证系统无故障稳定运行?
为了回答这个问题,就需要在系统上线前做多轮压力测试,提前模拟出复杂的 高仿真的线上流量来验证整体系统的高可用性 这也是实施系统高可用方案的关键环节。另外 通过不同阶段的压测,也完成对系统的容量规划、瓶颈探测,对系统整体能力进行验收,确保在突发的流量洪峰来临前,系统确实能够承受即将来临的真实线上压力。
从某种意义上来说,压测是系统稳定性的验证者。
如何实施一次准确的性能压测准备压测环境
压测的执行环境是一个老生常谈的话题,如果直接在生产环境执行压测,会有2个问题:
- 会影响线上业务,对正常访问系统的用户造成影响
- 会污染线上数据,将压测数据写入线上数据库
为了解决这 2 个问题,一般业内采用如下几种方案:
以上方案各有优缺点,适用场景也不尽相同,可以根据自己项目所处的阶段灵活选择方案。
构建压测脚本
业内常用的压测工具包括 JMeter、Gatling、Locust、k6、Tsung、阿里云 PTS 等。这些工具无一例外,都需要将压测业务的 API,编排为一个压测脚本。
这一步工作的重点在确认压测的 API,不要有遗漏,且 API 编排的顺序要符合用户的操作逻辑。对于健康码业务的压测来说,如果脚本中遗漏了登录鉴权 API,那后面的刷新健康码、查看核酸报告等 API 都会在权限校验这步就报错,不会执行正常的业务逻辑,也就无法模拟真实的业务场景。
以上压测工具编排脚本都有 2 个方式:
- 手动输入脚本,这需要脚本的编写人员对业务非常熟悉,保证不会遗漏API。
- 自动录制脚本,上述开源压测工具都提供了录制请求的代理功能,开启并配置代理后,只要在页面上模拟用户的操作和点击行为,即可自动录制请求,并生成压测脚本。同时 PTS 还提供了 Chrome 录制插件[1],免代理配置,可以一键生成 JMeter 和 PTS 压测脚本。提升了脚本编写的效率,也能保证不遗漏 API。
为了避免复杂脚本中遗漏 API 的风险,推荐使用录制功能生成脚本。
确认压力模型
这一步是在配置压测中模拟的压力峰值、不同 API 的压力分布比例以及压力值递增模型。压力值指的是模拟并发用户数,或每秒发送的请求数。
施压模式
在设置之前,需要确认施压模式,业内主要有 2 种施压模式:
- 虚拟用户(VU)模式,可以理解为一个线程模拟一个真实用户,压测时线程一直循环执行,模拟用户不停地发送请求。
- 吞吐量模式,即每秒请求数(QPS),可以直接衡量服务端的吞吐量。
在项目验收阶段,很重要的一个指标就是系统的吞吐量,即可支持的QPS。对于这种压测场景,更推荐使用吞吐量模式,可以直观的看到施压机每秒发出的请求数,并和服务端的吞吐量直接对应起来。
各 API 压力分布比例
确认了施压模式后,需要配置不同 API 的压力分布比例。比如健康码业务,100% 的用户会调用登录 AP 和获取健康码 API,但后面并不是所有用户都会调用查询核酸报告 API、查看推送信息等 API。所以每个 API 的准确压力分布比例,也是一次成功压测中不可获取的因素。
压力值递增模型
常见有脉冲模型,阶梯递增,均匀递增。
脉冲模型会模拟流量在瞬间突然增大,常用于秒杀、抢购的业务场景。
递增模型可以模拟在一定时间段内,用户量不断增大,常用于模拟有预热的业务场景。
除了常规的递增模型,最好在压测中可以实现手动调速功能,一是可以模拟一些非常规的流量递增情况,二是可以反复调整压力值,来复现和排查问题。
施压流量地域分布
确定了压力值和递增模型后,还需要确定施压流量的地域分布,应尽量拟合真实的用户分布,才能保证测试结果真实可信。
对于区域性的在线业务,施压机分布在当地的同一机房,是可以理解的。如果是全国性的在线业务,施压机也应该按照用户分布,在全国各地域部署。
执行压测,观察压测指标
压测中核心指标:请求成功率,请求响应时间(RT),系统吞吐量(QPS)
请求成功率不止要看全局的请求成功率,还要关注一些核心API的成功率,避免整体成功率达标,核心 API 成功率不足的情况。
请求响应时间,需要关注 99、95、90、80... 等一些关键分位的指标是否符合预期,而平均响应时间没有太大的参考意义,因为压测需要保证绝大部分用户的体验,在不清楚离散程度的情况下,平均值容易造成误判。
系统吞吐量是衡量系统能承受多大访问量的指标,是压测不可缺少的标准。
上面三个指标遇到拐点时,就可以认为系统已经出现性能瓶颈,可以停止压测或调小压力值,准备分析、定位性能问题了。
除了这三个业务指标,同时还应该同时观测系统的应用监控、中间件监控和硬件监控的一些指标,包括但不限于:
服务器:
- 网络吞吐量
- CPU 使用率
- 内存使用率
- 磁盘吞吐量
- ......
数据库:
- 连接数
- SQL 吞吐量
- 慢 SQL 数
- 索引命中率
- 锁等待时间
- 锁等待次数
- .....
中间件:
- JVM GC 次数
- JVM GC 耗时
- 堆内、堆外内存使用量
- Tomcat 线程池活跃线程数
- ......
更多压测时需要关注的指标,见压测指标[2]
如果系统已经达到预期,往往还可以可以按照 10-20% 的比例,不断加大压力值,为系统做一次峰值“摸高”,观察系统的极限值是多少,做到心里有底。
复盘,性能优化
压测结束,如果未达到预期,可以配合监控排定位,分析性能问题,性能优化完成后,在下一轮压测中继续验证。
测试中问题分析和调优的方法这里不展开描述,可以参考这篇测试问题分析及调优[3]。
如果系统表现已经符合预期,可以用压测得到的系统吞吐量指标,配置流控、降级、系统或隔离规则,保障系统稳定性。
作者:拂衣、风云
原文链接:http://click.aliyun.com/m/1000323921/
本文为阿里云原创内容,未经允许不得转载。