本文是《Performance Test Together》（简称 PTT）系列专题分享的第二期，该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解，以帮助大家构建完整的性能压测的理论体系，并提供有例可依的实战。
该系列专题分享由阿里巴巴 PTS 团队出品，欢迎添加小姐姐联系方式（zjjxg2018），参与该系列的 GitChat 分享。
第一期：《压测环境的设计和搭建》，点击这里。
本文致力于给出性能压测的概念与背景介绍，同时针对市场上的一些性能压测工具，给出相应的对比，从而帮助大家更好地针对自身需求实现性能压测。
在介绍性能压测概念与背景之前，首先解释下为什么要做性能压测。从 09 年的淘宝双十一大促导致多家合作银行后台系统接连宕机，到春运期间 12306 购票难，再到前不久聚美优品促销活动刚开始就遭秒杀。根据 Amazon 统计，每慢 100 毫秒，交易额下降 1%。这些事件和统计数据为大家敲响了警钟，也客观说明了性能压测对于企业应用的重要性。
从具体的作用上讲，性能压测可以用于新系统上线支持、技术升级验证、业务峰值稳定性保障、站点容量规划以及性能瓶颈探测。
1. 新系统上线支持
在新系统上线前，通过执行性能压测能够对系统的负载能力有较为清晰的认知，从而结合预估的潜在用户数量保障系统上线后的用户体验。
2. 技术升级验证
在系统重构过程中，通过性能压测验证对比，可以有效验证新技术的高效性，指导系统重构。
3. 业务峰值稳定性保障
在业务峰值到来前，通过充分的性能压测，确保大促活动等峰值业务稳定性，保障峰值业务不受损。
4. 站点容量规划
通过性能压测实现对站点精细化的容量规划，指导分布式系统机器资源分配。
5. 性能瓶颈探测
通过性能压测探测系统中的性能瓶颈点，进行针对性优化，从而提升系统性能。
综上所述，性能压测伴随着系统开发、重构、上线到优化的生命周期，因此有效的性能压测对系统的稳定性具有重要的指导意义，是系统生命周期中不可或缺的一部分。
性能压测是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
从测试目的上性能压测又可以划分为负载测试、压力测试、并发测试、配置测试以及可靠性测试。
总的来说，性能压测是在对系统性能有一定程度了解的前提下，在确定的环境下针对压测需求进行的一种测试。
在选取合适的性能压测工具之前，我们需要先先了解执行一次完整的性能压测所需要的步骤：
1. 确定性能压测目标：性能压测目标可能源于项目计划、业务方需求等
2. 确定性能压测环境：为了尽可能发挥性能压测作用，性能压测环境应当尽可能同线上环境一致
3. 确定性能压测通过标准：针对性能压测目标以及选取的性能压测环境，制定性能压测通过标准，对于不同于线上环境的性能压测环境，通过标准也应当适度放宽
4. 设计性能压测：编排压测链路，构造性能压测数据，尽可能模拟真实的请求链路以及请求负载
5. 执行性能压测：借助性能压测工具，按照设计执行性能压测
6. 分析性能压测结果报告：分析解读性能压测结果报告，判定性能压测是否达到预期目标，若不满足，要基于性能压测结果报告分析原因
由上述步骤可知，一次成功的性能压测涉及到多个环节，从场景设计到施压再到分析，缺一不可。工欲善其事，必先利其器，而一款合适的性能工具意味着我们能够在尽可能短的时间内完成一次合理的性能压测，达到事半功倍的效果。
在论述了性能压测必要性之后，如何选取性能压测工具成为一个重要的议题？本文选取了市场上主流性能压测工具：（ab）Apache Bench、LoadRunner、JMeter、阿里云 PTS，并从多个方面出发分析了各个工具的优缺点，汇总后的优缺点如下表所示：
| 压测工具 | Apache Bench（ab） | LoadRunner | JMeter | PTS |
|---|---|---|---|---|
| 学习成本 | 低 | 高 | 高 | 低 |
| 安装部署成本 | 低 | 高 | 高 | 低 |
| 是否免费 | 是 | 否 | 是 | 否 |
| 是否支持多协议 | 否 | 是 | 是 | 是 |
| 压测结果是否能够图形化展示 | 否 | 是 | 是 | 是 |
| 是否支持 TPS 模式 | 否 | 否 | 否 | 是 |
| 是否有链路、场景编排管理支持 | 否 | 是 | 是 | 是 |
| 是否支持场景录制 | 否 | 是 | 是 | 是 |
| 生态环境强弱 | 弱 | 弱 | 弱 | 强 |
| 监控指标是否完备 | 否 | 否 | 否 | 是 |
| 是否原生支持流量地域定制 | 否 | 否 | 否 | 是 |
ab 是一款用来针对 HTTP 协议做性能压测的命令行工具，支持在本地环境发起测试请求，验证服务器的处理性能。它主要具有以下特点：
首先，作为一款开源工具，ab 具有较好的扩展性，测试开发人员可以基于自身需求对其进行二次开发，同时它对 HTTP 协议支持度较好，比如支持设定 HTTP 请求头、支持 Cookie 以及 HTTP 的多种方法。
此外，使用 ab 时还可以通过指定性能压测产生的总请求数、并发数与压测时长控制性能压测，结合其能够输出性能压测过程中的 TPS（每秒事务数）、RT（响应时延）等信息的特点，ab 具有简单易上手的特点。
但 ab 也存在一些缺点，如无图形化界面支持，支持协议较为单一，只支持 HTTP 协议，缺少对 HTTPS 协议、WebSocket 等协议的支持，对于较为复杂的性能压测场景，ab 缺少链路编排、场景管理等支持，只能够对单一地址发起性能压测，此外，它的性能压测统计指标纬度较少，缺少性能压测过程中的数据统计，只能够在压测结束后获取相关的统计数据，无法实时获取系统负载等指标，难以应用于生产环境下的性能压测。
总的来说，ab 作为一款命令行测试工具，适用于本地对支持 HTTP 协议的单一地址进行性能压测，但缺少相应的链路编排、场景管理、数据可视化等大规模性能压测基础功能，无法应用于生产环境。
LoadRunner，是一款发布于 1993 年 11 月的预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 作为一款历史悠久的商业性能压测工具，能够对整个企业架构进行测试。企业使用 LoadRunner 能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner 可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。
LoadRunner 从组件上可划分为四部分：
从组件划分上可以看出 LoadRunner 对于性能压测拥有较为系统的支持，结合多个组件的功能特性，用户可以较为方便地设计复杂背景下的性能压测场景，例如结合场景设计设置虚拟用户数量、设置执行时间等，结合虚拟用户生成器实现复杂链路、场景的高效设计与编排。
此外，LoadRunner 支持设置思考时间、集合点，还可以结合分析器实现压测报告统计数据、指标的可视化，助力测试人员理解性能压测结果。
但 LoadRunner 作为一款商业软件，价格较高，需要本地安装，安装过程较复杂，在实际设计执行压测时需要编写相应的脚本，对使用人员来说学习成本比较高，此外缺少监控告警等支持，性能压测过程中难以实时发现问题。
总的来说，LoadRunner 作为一款性能压测商业软件，功能较为齐全，使用者能够借助 LoadRunner 达到简单的性能压测场景编排、施压目标；但它也存在学习成本居高不下、扩展性差等缺点，此外支持的协议有限，不适合复杂的性能压测环境。
Apache JMeter 是 Apache 组织开发的基于 Java 的压力测试工具。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等。另外，JMeter 能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter 允许使用正则表达式创建断言。同时 JMeter 支持对性能压测结果做图形分析。
JMeter 作为一款开源软件，扩展性强，具有强大的开源社区支持，社区内开发者活跃程度高，也正是在开源社区的积极发展下，JMeter 具有性能压测的诸多特性，如支持场景编排、断言设置，支持对多种资源施压，有图形化界面支持，支持脚本录制，使用人员能够较为简单的设计并发起性能压测，此外 JMeter 提供资源监控、性能压测报告生成等功能。
但在需要高负载施压的场景下，JMeter 需要部署分布式环境，部署成本比较高，在使用时，需要编写相应的脚本，而每个脚本文件只能保存一个测试用例，学习门槛居高不下的同时也不利于脚本的维护，此外它缺少监控告警等支持，在性能压测过程中使用人员难以借助 JMeter 实时发现问题。
作为一款时下热门的开源性能压测工具，根据谷歌搜索指数显示，JMeter 已经逐渐展现出了替代 LoadRunner 的趋势，如图：
同时活跃的社区环境、开发者生态也进一步促进了 JMeter 的功能完善，未来的发展值得期待。但于此同时，JMeter 也存在学习、维护成本高，缺少监控告警等功能支持，难以应用于大型复杂的性能压测场景。
性能测试服务（Performance Testing Service，简称 PTS）是一个 SaaS 性能测试平台，提供场景 API 编排功能。结合阿里巴巴的自研平台和引擎，支持按需设定压测模式、压测量级、压测时间，快速发起压测，监控压测过程并生成报告等功能，同时也兼容开源工具 JMeter。
下面将从功能、性能、生态与监控四个方面展开介绍 PTS：
功能方面
PTS 提供了链路、场景编排压测报告导出的功能、，除了传统的并发模式（虚拟用户并发），PTS 也支持 RPS 模式（Requests per Second），也即吞吐量模式，RPS 模式为 PTS 独有，具有能够更精准地衡量服务端系统能力等优点。为了降低发起性能压测的门槛，PTS 提供云端录制器，便于客户端的请求抓取，同时还可将抓取的请求一键导入到压测场景中；为了适配不同场景下的性能压测，PTS 支持创建服务等级协议 SLA（Service Level Agreement）规则，能够实现对业务压测场景更智能的控制和更全面合理的评价，同时，PTS 也提供了大量 SLA 模板供不同背景下的用户使用；此外，PTS 还支持定时压测，能够指定启动压测的日期、时间以及循环周期等，能够在任意时间段自由发起性能压测，释放人力。
性能方面
PTS 能够随机调度遍布全国各地的压测引擎，一分钟内快速启动性能压测，模拟真实环境下的用户请求；支持最高千万级的流量瞬时脉冲，多重机制确保压测流量及时停止；支持两种调速模式：自动递增和手动调整，压测流量调整秒级生效。
生态方面
PTS 支持添加阿里云生态内的云监控产品，如添加阿里云生态内的性能管理类产品 ARMS，提供应用级别的监控，为性能压测提供问题定位的闭环能力；此外 PTS 云端集成 JMeter，用户只需在本地完成 JMeter 脚本调试，即可在 PTS 上快速发起压测。
监控方面
PTS 监控指标包括每个 API 的并发，RPS (Requests per Second)、响应时间、采样的日志等。同时从不同细分维度，统计了 API 请求的成功、失败情况和响应时间，能够帮助用户快速定位到系统的性能瓶颈。此外，PTS 还能够结合阿里云生态内的云产品监控，如监控 ECS、SLB 及 RDS 等在内的各产品性能指标；为云上服务提供更为详尽的监控。
总的来说，阿里云 PTS 作为一款云服务，用户可以较低的学习成本快速借助 PTS 发器压测，对于阿里云的用户来说，PTS 能够紧密结合现有的阿里云服务，提供全方位的压测报告供用户快速定位性能瓶颈；对于 JMeter 用户，也能够以较低的成本迁移至 PTS，享受 PTS 的高阶功能。但 PTS 也存在一些问题，扩展性需要加强，例如需要支持更多网络协议。
某创业公司 A 即将上线一项新功能，为了在上线前充分测试，保障服务的高可用性，测试人员给出了相应的测试需求：
为了尽可能避开业务高峰期，需要在每天的凌晨一点钟测试；
测试时，认为业务的正常响应时间应当在 550 ms 以下，连续三次响应时间超出 550 ms 时应当向负责人发出通知，连续三次响应时间超出 800 ms 则应当停止压测；
为了模拟真实的用户流量，需要设置流量一半来源于移动运营商，一半来源于联通运营商；
公司希望在对自身业务监控的同时，能够监控到所使用阿里云上 ECS、RDS 等云服务的资源使用状态；
结合上述的各性能压测工具优缺点，仅有 PTS 满足客户需求，下面我们具体看一下 PTS 如何实现该案例需求。
首先为了能够实现每天凌晨一点测试，我们可以使用 PTS 所提供的定时压测功能，通过把场景设置为定时压测任务，结合 cron 表达式可以实现每天凌晨一点自动运行该压测场景，配置如下图所示：
接着为了实现连续三次响应时间超出 550 ms 后，向负责人发送通知；连续三次响应时间超出 800 ms 停止压测，可以利用 PTS 所提供的 SLA 功能实现，配置如下图所示：
在配置 SLA 规则后，还可以设置 SLA 规则应用链路，以及报警通知人，如下图所示：
接下来为了能够实现流量一半来源于移动运营商，一半来源于联通运营商，我们可以利用 PTS 所提供的流量地域定制功能，指定压测引擎运营商，如下图所示：
最后，为了能够在压测过程中以及压测报告中查看到阿里云 ECS、RDS 等监控状态，可以在添加监控中添加对应的监控项，如下图所示：
综上，PTS 的各项配置成功地满足了该创业公司的压测需求，在避免员工夜间值班压测，节省了公司人力资源的同时，提升了该公司的性能压测效率，在最终的压测报告中，客户可以观察到业务的性能指标以及所使用云服务的资源使用状态，通过对压测报告的解读可以快速定位到服务的性能瓶颈，提升服务质量。
本文介绍了性能压测的概念以及相关背景，并针对目前几款受众相对较多的性能压测工具给出了优缺点分析，每种工具都有相应的优缺点，大家可以针对自身需求选取合适的性能压测工具。
本文介绍了性能压测的概念以及相关背景，并针对目前几款受众相对较多的性能压测工具给出了优缺点分析，每种工具都有相应的优缺点，大家可以针对自身需求选取合适的性能压测工具。
不当之处，欢迎留言指正。
** 本文作者：**
风起，阿里云 PTS 开发工程师，专注于性能压测与高可用架构领域。
