云时代的应用性能测试挑战
系统容量相比传统应用数量级增长 微服务化架构,调用关系更加复杂 用户增长迅速,资源突发需求量大
▼▼▼
传统性能测试工具性能不足,自研技术门槛高 瓶颈在各微服务间漂移,测试技术难度大 如何摸清资源扩容模型,有限资源下如何验证性能 一旦性能问题流入现网,问题定位周期长
华为云性能测试实践方案如何更加系统的开展性能测试活动
1. 被测对象分析(某社交类APP)
从系统架构分析可能出现的瓶颈点,作为重点测试场景
Feed流会频繁操作后台的Redis等服务,每次操作会产生100+次网络操作,200+次key/Value运算,因此会成为系统的主要性能瓶颈 备注:Feed是将用户主动订阅的消息源组合在一起形成内容聚合器,帮助用户持续地获取最新的订阅源内容,在社交类应用中被广泛使用若干
2. 测试场景分析建模
业务特点:用户增长迅速、突发事件高流量并发
Step1:以使用场景为主线,构建性能模型(使用角色、使用阶段等)
Step2:分析每个操作场景的影响因子,如好友、关注数量等,建立每个场景的测试模型 单场景一级接口测试
单场景二级接口测试
如需测试某个对性能的影响,可递增方式改变因子值进行测试
按照页面权重分配压力模型,实际在生产环境比例会不断变化,因此在性能摸底过程中需要不断调整摸底
示例:全页面混合压测模型
3. 测试工具需求分析
识别关键场景测试需求
-
HTTP协议/Rest接口
-
用户登陆认证 ,模拟多用户操作
-
支持接口串联场景,需要上下文关联
-
性能暂无基线,需要支持递增模式快速摸底
-
各页面用户量未知,需要灵活调整混合模型配比
-
由于社交类应用业务增长迅速,因此需要支持按需使用,随时扩大工具的并发量
-
需要支持10万以上的并发
-
测试结果易于观察、保存
-
提供监控能力,便于快速定位
4. 测试服务选型与搭建
测试服务选项原则:功能满足、效率高(即开即用)、成本低
华为云性能测试服务CPTS更适合测试高扩展性的大规模分布式系统
5. 测试执行
分层开展性能测试,在集成阶段确保性能测试活动可开展
测试执行的一些典型问题 性能是一个逐步提升的过程,测试过程中需要找到扩容的模型,从不足50的TPS提升至万级
6. 测试结果分析
1.1 如何从测试工具侧快速分析被测对象可能存在的问题
-
存在部分响应超时: a) 服务器繁忙,如某个服务节点CPU利用率高 b) 网络IO超过VM/EIP带宽 c) 等待后端微服务、数据库的超时时间设置过长
-
运行一段时间后全部响应超时或者检查点校验不通过: a) 大压力导致系统中某个微服务奔溃 b) 后端数据库无响应
-
TPS未随着并发数增长而上升: a) 系统性能到达瓶颈,持续并发加压过程中响应时延增加(可观察响应区间统计) b) 可通过进一步加压是否会出现非正常响应验证
-
TP90响应时延较短,TP99时延高: a) 系统性能接近瓶颈 b) 可通过进一步加压是否会出现非正常响应验证
1.2 一些通用优化建议
-
扩容,链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快,这一类需要横向扩展资源。
-
应用逻辑优化,比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。
-
超时时间的合理设置,对于应用之间的rpc调用或者应用与其他基础组件之间的调用,均需要设置合理的超时时间,否则过长的等待将造成整个链路的故障。
-
缓存的应用,请求尽可能从前端返回,而不是每一个都要让后端应用处理后再返回,减轻后端应用及数据库压力,提高系统吞吐能力。
-
限流,对于超出承载能力的QPS或并发,可以进行拦截并直接返回提示页面。
-
降级,对于非核心链路上的应用,允许故障关闭而不影响核心链路
-
扩容和优化也是有限度的,在评估容量内,保障核心交易链路正常是重中之重,对于非核心功能模块考虑降级场景
某互联网平台案例
业务特点:突发事件高流量突发,如瞬间由百级用户增长到万级
对于网络架构复杂的应用,可以通过网络架构上的分段验证,如分别从最外端的CDN入口(1)中间的ELB(2)业务层(3)分别做测试,验证网络架构上的瓶颈和影响