分布式系统全链路压测方法

目录

前言

测试策略

核心目标

技术选型

报告输出

总结

---

前言

继上一篇JMeter的基本使用介绍（使用Apache JMeter做压力测试），本文介绍如何做分布式系统的全链路压测。压测也叫基准测试（benchmark），通常的目标是为了掌握系统的行为，或者做系统的可靠性测试，从更大的层面上讲，压测可以学习系统在给定的工作负载下会发生什么变化，掌握哪些是重要的变化，压测的重要性由此体现。

全链路压测实施的核心流程如下：

测试策略

要明确测试策略，有几个重要的问题首先要回答：

1. 测试环境如何准备？

数据库一般的要使用真实数据的全集，最好将生产环境的数据脱敏导出，方式多种多样，一般的工具可以模拟影子库，或者将生产环境的数据库快照导出，具体需要了解一些数据库的基础知识可以快速有效的达到目的。应用层面最好模拟真实的用户分布，如JMeter可以采用参数化模拟不同的用户token，集合点和随机顺序控制器分别模拟强弱并发。整体的就是越接近生产环境的真实情况越好，当然这个本来就很难，而且做的时候也只能无限接近。

2. 测试何种指标？

性能的指标有很多种，对于不同的系统如OLTP和OLAP系统，或者I/O密集型的应用或者CPU密集型的应用，不同的系统测试策略大相径庭。像我们的企业级应用一般是属于OLTP系统，要更多的关注全链路的性能，包括应用层和数据库层，API响应时间和事务吞吐量TPS是最为关注的指标。对于一个分布式系统，更多的要关注到并发和扩展性，扩展性也叫水平可伸缩性，也就是说给系统增加机器能否获取线性的性能提升。

3. 测试目标设定在哪里？

不同的系统在设计的时候目标不一样，一个2B的企业内部管理系统肯定不会按照2C的电商系统一样的目标设计，单体式应用和分布式应用的关注点和目标也不尽一样，所以要因地制宜选取合适自己的目标、指标和时间。具体来说一个月活跃用户1600的企业内部管理系统，可以将目标设定在160-320并发，单接口响应时间（P90）少于1秒，错误率小于1%，整体吞吐量TPS大于300等等。在获取到准确的结果后，尽可能采用绘图的方式分析结果，如matplotlib、R、Python或Excel。

图1. 压测基本思路

明确了测试策略后，需要有一个基本思路来作为指导，否则也无从开始。如上图1则抽象了一个基本思路是基于月活跃用户确定执行的并发数，然后用工具模拟压力输出报告，最终我们关心的三个最重要的指标是响应时间、错误率、吞吐量。过程中要执行强弱并发压测、极值测试、数据翻倍测试来对当前的系统性能现状客观评估，并对未来长时间的运营提供足够建议。

名词解释

吞吐量：反馈系统整体性能很重要的一个指标，也有几个衡量的维度，如QPS、TPS、网络收发的数据量，不同的系统应该采用不同的衡量标准，一般的在线事务处理型系统会选取TPS，但也不一定客观，因为在系统跟系统横向对比的时候不一定能量化系统性能，因为实际的吞吐量受到调用栈、报文大小和网络环境等的影响，所以还是要因地制宜。

强并发：所有用户（请求）集合到一起同时访问系统。

弱并发：所有用户（请求）有序或无序进入，进入一个处理一个。

Average（平均响应时间）：接口响应时间的平均值。

P90（90%响应时间）：接口有90%的响应时间，都低于(优于)该值。

Error%（错误率）：所有的事务执行后失败的事务在所有事务中的比例。

核心目标

由于各系统在系统架构和部署方式千差万别，需要具体分析，设置好一个比较合理的标的是非常重要的。如某系统我们设置的核心目标是各场景在100并发下，超时率<=5%，单接口响应时间<=3s，总体吞吐量TPS >= 100。

可以先不论目标的高低、系统的优劣，只讨论测试本身，那么为了达到这样的目标，数据要翻倍，环境要监控，脚本要录制，另外很重要的是开发团队是要做一些配合修改的，大的层面可以从前后端调优、数据库调优、部署参数调优等各方面考虑。一个典型的分布式系统还要增加以下几个方面的关注维度：

1. 全链路监控而不是单应用监控，可以借助
2. 系统的水平扩展性也就是增加机器后性能的提升指数
3. 系统的可用性即异常情况下的恢复能力

技术选型

序号	方案	优点	缺点	备注
1	LoadRunner	1、高度自动化 2、可推广性强	1、环境准备复杂，需要更长的环境准备时间 2、无法排除网络干扰（丢包的情况下压测不通过，无法生成报告，大并发量无法模拟）
2	阿里云PTS	1、可直接在生产环境进行全链路压测（影子库、切流量） 2、可VPC内网连接测试环境，排除网络干扰，成功率高	1、需要购买资源包	PTS资费：预付费¥1,058.00/年(40万VUM)
3	JMetter	1、低成本，环境准备时间短，功能完善	1、需要手动编排压测场景API，人力投入大	最终选择

表2. 技术选项

如上表2，最终的选择是基于JMeter的各种控制器以及集合点的设置，模拟强弱并发和不同用户访问系统的情况。但是在资金充足需要快速验证的情况下，可以选择阿里云性能测试工具PTS，其最大的特色就是可以直接在生产环境执行全链路压测（如下图）。

报告输出

压测报告是承载系统性能现状很重要的体现，一个好的压测报告不仅要客观的反映现状，还需要提出合理化建议，体现出专业性和洞察力。

图3. 聚合报告

图4. 服务器资源采集

图5. 推导分析 

如上图3、图4、图5所示，基本的测试报告至少应该包含几个核心章节如优化目标、测试环境、测试策略及结果、结论，其中测试策略需要区分单场景/组合场景的强弱并发、稳定性测试、极限压力测试等，往往不会是单纯一个测试，而是按照不同的测试目标来区分的，如强并发一般设置一个用户集合时间，一起并发的访问系统，探测系统在洪峰下的表现；稳定性测试一般都没有设置用户集合，而是按照随机顺序的方式给每个场景设置一定的并发，场景和场景之间没有并行关系，持续运行8小时以上，以此类推。

一般为了分析结果，报告的最后需要给一个结论及推导，在表格数据的基础上配以图表辅助理解数据，下面给出某客户压测报告目录示例。

目录

1 概述 1

1.1 本次性能优化的原因 1

1.2 本次性能优化的核心目标 1

1.3 名词解释 1

2 测试环境 2

2.1 业务主表数据量统计 2

2.2 测试环境账号信息 3

2.3 测试环境拓扑 4

2.4 测试主要环境配置 4

3 浏览器测试结果 5

3.1 测试策略 5

3.2 Chrome浏览器响应时间 6

3.3 IE浏览器响应时间 8

4 组合场景并发测试结果 11

4.1 测试策略 11

4.2 组合场景测试结果 12

4.3 聚合报告 15

4.4 服务器资源采集分析 15

4.4.1 Web服务器 15

4.4.2 Redis服务器 17

4.4.3 MySQL服务器 17

4.5 交易数据翻倍测试结果 18

4.5.1 交易数据翻三倍测试结果 18

4.5.2 交易数据翻五倍测试结果 19

4.5.3 服务器资源采集分析 20

5 稳定性测试 21

5.1 测试策略 21

5.2 稳定性测试结果 21

5.3 聚合报告 23

5.4 服务器资源采集分析 23

6 极限压力测试 24

6.1 测试策略 24

6.2 极限压力测试结果 24

6.3 聚合报告 26

6.4 服务器资源采集分析 26

7 结论 27

总结

本文的最后总结一下分布式系统全链路压测的重点：

1. 测试策略：强弱并发、稳定性、极值测试
2. 衡量指标：响应时间、错误率、吞吐量
3. 目标设定：各场景在xxx并发下，超时率<=x.x%，单接口响应时间<=x，总体吞吐量TPS >= xxx
4. 技术选型和环境准备：合理模拟真实数据，JMeter Linux CLI运行（屏蔽网络干扰），监控全链路的性能指标而不是单应用的
5. 报告整理：核心章节要体现如优化目标、测试环境、测试策略及结果、结论