大规模分布式系统性能测试实践

云时代的应用性能测试挑战

系统容量相比传统应用数量级增长
微服务化架构，调用关系更加复杂
用户增长迅速，资源突发需求量大
▼▼▼
传统性能测试工具性能不足，自研技术门槛高
瓶颈在各微服务间漂移，测试技术难度大
如何摸清资源扩容模型，有限资源下如何验证性能
一旦性能问题流入现网，问题定位周期长

华为云性能测试实践方案如何更加系统的开展性能测试活动

1. 被测对象分析（某社交类APP）
从系统架构分析可能出现的瓶颈点，作为重点测试场景

Feed流会频繁操作后台的Redis等服务，每次操作会产生100+次网络操作，200+次key/Value运算，因此会成为系统的主要性能瓶颈
备注：Feed是将用户主动订阅的消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容，在社交类应用中被广泛使用若干

2. 测试场景分析建模

业务特点：用户增长迅速、突发事件高流量并发
Step1：以使用场景为主线，构建性能模型（使用角色、使用阶段等）

Step2：分析每个操作场景的影响因子，如好友、关注数量等，建立每个场景的测试模型
单场景一级接口测试

单场景二级接口测试

如需测试某个对性能的影响，可递增方式改变因子值进行测试
按照页面权重分配压力模型，实际在生产环境比例会不断变化，因此在性能摸底过程中需要不断调整摸底

示例：全页面混合压测模型

3. 测试工具需求分析

识别关键场景测试需求

1. HTTP协议/Rest接口
2. 用户登陆认证 ，模拟多用户操作
3. 支持接口串联场景，需要上下文关联
4. 性能暂无基线，需要支持递增模式快速摸底
5. 各页面用户量未知，需要灵活调整混合模型配比
6. 由于社交类应用业务增长迅速，因此需要支持按需使用，随时扩大工具的并发量
7. 需要支持10万以上的并发
8. 测试结果易于观察、保存
9. 提供监控能力，便于快速定位

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 一些通用优化建议

1. 扩容，链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快，这一类需要横向扩展资源。
2. 应用逻辑优化，比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。
3. 超时时间的合理设置，对于应用之间的rpc调用或者应用与其他基础组件之间的调用，均需要设置合理的超时时间，否则过长的等待将造成整个链路的故障。
4. 缓存的应用，请求尽可能从前端返回，而不是每一个都要让后端应用处理后再返回，减轻后端应用及数据库压力，提高系统吞吐能力。
5. 限流，对于超出承载能力的QPS或并发，可以进行拦截并直接返回提示页面。
6. 降级，对于非核心链路上的应用，允许故障关闭而不影响核心链路
7. 扩容和优化也是有限度的，在评估容量内，保障核心交易链路正常是重中之重，对于非核心功能模块考虑降级场景

某互联网平台案例

业务特点：突发事件高流量突发，如瞬间由百级用户增长到万级

对于网络架构复杂的应用，可以通过网络架构上的分段验证，如分别从最外端的CDN入口（1）中间的ELB（2）业务层（3）分别做测试，验证网络架构上的瓶颈和影响

性能测试服务关键能力要求