性能测试系列（二）

1 业务角度下， 哪些情况需要做性能测试
1.1 业务使用频率高
业务功能频率极高使用情况下，要有性能测试报告（如app账本，今日交易近期日午高峰，达到90k/分钟），具体可以参考zeus

1.2关键业务且日请求量高
关键业务且日请求量很高，系统压力很大情况下，要有性能测试报告（如支付操作，午高峰和晚高峰很明显）

1.3 用户体验被要求极度重要
业务为关键业务，用户体验被要求极度重要（如门店码支付，主要是唤起收银台，完成交易要响应快）

1.4 热配置加载、降级、熔断等
支付网关动态配置工作线程，需要在一定压力背景下演练
支付网关网联切银联(午高峰网联故障)演练
1.5 秒杀场景

2 系统角度下， 哪些情况需要做性能测试
2.1 核心服务
业务架构里的基础核心服务，比如支付网关、core-b、红包服务

2.2 并发量大的服务
系统需要承载午高峰、晚高峰场景，比如终端管理平台TPS

2.3 系统架构发生变更、重构等
系统架构为新的或者是发生变更时，且有性能要求时，要有性能测试报告

支付网关3.0
依赖的核心服务做了重构，需要自身评估，比如core-b重构
2.4 引入三方服务
接入三方sdk，比如apollo配置中心（引入其sdk是否对我性能产生影响）
接入中间件，比如rabbitmq切到kafka，mongo转到mysql
物理机部署转到docker化，docker转到k8s
比如支付网关需要评估支付宝、微信等支付源性能好坏对于自身的影响

3 如何做性能测试
3.1 架构的分析
是否是关键路径
缓存的刷新机制
分布式锁
数据库的体量
涉及到rabbitmq的是否有补偿机制
3.2 业务的梳理
业务之间的调用关系
业务的接口列表
接口类型
读接口还是写接口
3.3 压测数据的准备
测试数据之间的比例关系，比如商户、门店、终端之间的比例
是否分库分表，sharding的规则* 避免数据库单点过热

• 单个商户的订单量过大，影响实际报表查询返回
  数据的时效性，比如查询操作，如果数据过期了，会引起大量的缓存刷新
  3.4 压测的姿势
  少量并发预热
  逐步增大并发量，寻找系统的抛物线最优点
  在最优点进行稳定性测试、健壮性测试* 支付源通道异常演练等
• 热配置加载
• 降级、熔断（比如支付网关ip限流）
• 水平扩容
• 服务升级
  响应时间不要用平均响应时间，关注95线；
  吞吐量考虑响应时间变化；
  吞吐量需要和成功率挂钩；
  3.5 压测报告
  吞吐量
  相应的CPU、MEM
  根据业务是否监控磁盘IO、网络带宽
  基础中间件的性能指标