性能测试需求分析案例

有同学问了这样一个问题：一个新服务上线需要压测，业务类型为订单业务，数据库采用的是 MySQL 且分库分表，在开展性能测试时有哪些注意事项？

这是一个很典型且较为常见的性能需求，很多新手在面对这种性能需求时却经常犯错，常见的误区有直接压测 MySQL、用工具直接模拟高并发、测试数据量较小甚至重复等现象。

在以往分享的性能测试相关实践案例文章中，我一直强调一个认知：性能测试是一个系统的技术工程，实施之前一定要做好需求分析，然后设计好三大模型(业务模型+流量模型+数据模型)，最后才是执行压测。

如果从优先级和耗时占比来说，前期准备工作会耗费大量时间精力，反而执行阶段耗时较小且优先级要向后排。

以上述同学的问题为例，分析该性能测试需求一定要搞清楚如下几点：

1、本次性能测试的目的是什么？

是验证新服务的最大性能表现、安全容量，还是验证该新服务对应的技术架构性能和稳定性表现？

如果是验证最大性能表现和安全容量，那需要挑选出该服务的核心业务场景，并按照预估的线上流量和业务量制定流量模型，准备测试数据，然后再执行压测。

如果仅是验证该新服务技术架构(特指 MySQL 分库分表)的性能和稳定性表现，则创建 SQL 语句直接压测数据库即可。

目的不同，则具体的实施方案和准备事项不同。

2、如何设计该性能需求的三大模型？

设计出正确合理的性能测试三大模型，是性能测试能否正确开展的核心工作。

业务模型：订单业务的核心一般有创建订单、订单支付、订单列表、订单详情，这些都是正向业务流程，按照经验来说会占到订单服务大概 90%以上的流量。压测时一般仅需要验证这几个核心场景的性能表现即可。

流量模型：找到核心业务场景后，按照这几个业务场景的预估请求量占比(比如预计日均 1W 单，其中创建订单 5K、订单支付 3K、订单列表和订单详情各 1K)来制定流量模型。

流量模型的制定并不是拍脑袋制定的，一方面需要和业务方多沟通，另一方面还要考虑到技术实现的内部调用关系和调用次数，以及强弱依赖。如果有线上监控或线上已有服务(老订单服务)数据作为参考，则更好。

在制定流量模型时，还需要注意一点：流量模型的制定可以参考业务转化漏斗。

数据模型：有了业务模型和流量模型，数据模型的制定则比较简单。比如创建订单峰值 QPS 毛估 200，单次压测执行 10 分钟，则创建订单接口所需的测试数据，最少需 200*10*60=120000 条数据。

以此类推，准备好核心业务场景对应的 API 中，请求入参需要参数化的数据，然后执行压测即可。

3、独立的性能测试环境是性能测试能否正确实施的基础。

很多同学觉得性能测试不就是找个环境部署好服务，然后直接用工具模拟高并发嘛，很简单，其实不然。

独立的性能测试环境很重要，主要体现在如下几个方面：

1. 提前进行性能验证，发现并修复问题；

2. 独立的性能测试环境可以避免其他测试动作的影响；

3. 提前进行各种手段的性能测试，降低线上出现问题的修复成本；

至于是否有那个时间和成本预算搭建独立性能测试环境，因地制宜，是具体情况而定。

在成本和需求都满足的情况下，搭建独立性能测试环境可以参考如下几点建议：

1. 和生产等比最小化，即 1 个服务 1 台机器；

2. 如果是云服务，尽量部署在不同可用区；

3. 机器配置类型和生产保持一致(cpu 类型/几核几 G)；

4. 如果是云服务，选择按量收费，而不是包年(降低成本)；

5. 非核心服务(调用量不大/重要性低)，可以多个服务部署同一个机器；

6. 数据量缩小，数据库隔离降配(8C64G 的数据库实例足够满足日常压测所需)；

7. 该有的链路追踪/基础监控/应用监控等技术设施必须部署，便于问题定位排查；