效能压测工具选型对比_测试最新消息

本文是《Performance Test Together》（简称PTT）系列专题分享的第二期，该专题将从效能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对效能压测的全过程进行拆解，以帮助大家构建完整的效能压测的理论体系，并提供有例可依的实战。

该系列专题分享由阿里巴巴 PTS 团队出品。

第一期：《压测环境的设计和搭建》，点选这里（https://yq.aliyun.com/articles/704223?spm=a2c4e.11153940.0.0.31d548f5hGqSSS）。

本文致力于给出效能压测的概念与背景介绍，同时针对市场上的一些效能压测工具，给出相应的对比，从而帮助大家更好地针对自身需求实现效能压测。

在介绍效能压测概念与背景之前，首先解释下为什么要做效能压测。从09年的淘宝双十一大促导致多家合作银行后台系统接连宕机，到春运期间12306购票难，再到前不久聚美优品促销活动刚开始就遭秒杀。根据Amazon统计，每慢100毫秒，交易额下降1%。这些事件和统计资料为大家敲响了警钟，也客观说明了效能压测对于企业应用的重要性。

从具体的作用上讲，效能压测可以用于新系统上线支援、技术升级验证、业务峰值稳定性保障、站点容量规划以及效能瓶颈探测。

1. 新系统上线支援

在新系统上线前，通过执行效能压测能够对系统的负载能力有较为清晰的认知，从而结合预估的潜在使用者数量保障系统上线后的使用者体验。

2. 技术升级验证

在系统重构过程中，通过效能压测验证对比，可以有效验证新技术的高效性，指导系统重构。

3. 业务峰值稳定性保障

在业务峰值到来前，通过充分的效能压测，确保大促活动等峰值业务稳定性，保障峰值业务不受损。

4. 站点容量规划

通过效能压测实现对站点精细化的容量规划，指导分散式系统机器资源分配。

5. 效能瓶颈探测

通过效能压测探测系统中的效能瓶颈点，进行鍼对性优化，从而提升系统效能。

综上所述，效能压测伴随着系统开发、重构、上线到优化的生命周期，因此有效的效能压测对系统的稳定性具有重要的指导意义，是系统生命周期中不可或缺的一部分。

从测试目的上效能压测又可以划分为负载测试、压力测试、并发测试、配置测试以及可靠性测试。

总的来说，效能压测是在对系统效能有一定程度了解的前提下，在确定的环境下针对压测需求进行的一种测试。

在选取合适的效能压测工具之前，我们需要先先了解执行一次完整的效能压测所需要的步骤：

1. 确定效能压测目标：效能压测目标可能源于专案计划、业务方需求等

2. 确定效能压测环境：为了尽可能发挥效能压测作用，效能压测环境应当尽可能同线上环境一致

3. 确定效能压测通过标准：针对效能压测目标以及选取的效能压测环境，制定效能压测通过标准，对于不同于线上环境的效能压测环境，通过标准也应当适度放宽

4. 设计效能压测：编排压测链路，构造效能压测资料，尽可能模拟真实的请求链路以及请求负载

5. 执行效能压测：借助效能压测工具，按照设计执行效能压测

6. 分析效能压测结果报告：分析解读效能压测结果报告，判定效能压测是否达到预期目标，若不满足，要基于效能压测结果报告分析原因

由上述步骤可知，一次成功的效能压测涉及到多个环节，从场景设计到施压再到分析，缺一不可。工欲善其事，必先利其器，而一款合适的效能工具意味着我们能够在尽可能短的时间内完成一次合理的效能压测，达到事半功倍的效果。

在论述了效能压测必要性之后，如何选取效能压测工具成为一个重要的议题？本文选取了市场上主流效能压测工具：（ab）Apache Bench、LoadRunner、JMeter、阿里云PTS，并从多个方面出发分析了各个工具的优缺点，汇总后的优缺点如下表所示：

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 实时发现问题。

作为一款时下热门的开源效能压测工具，根据Google搜寻指数显示，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即将上线一项新功能，为了在上线前充分测试，保障服务的高可用性，测试人员给出了相应的测试需求：

结合上述的各效能压测工具优缺点，仅有 PTS 满足客户需求，下面我们具体看一下 PTS 如何实现该案例需求。

首先为了能够实现每天凌晨一点测试，我们可以使用 PTS 所提供的定时压测功能，通过把场景设定为定时压测任务，结合cron表示式可以实现每天凌晨一点自动执行该压测场景，配置如下图所示：