什么样的性能测试工具才算是好的工具呢？-编程知识

一、性能测试工具的特征

调度能力

因为性能测试不可能由一台压力机完成或者说大部分情况下，我们不能不可能由一台压力机来完成，凡是对压力真正有所要求的场景，往往是多台压力机共同施加压力完成性能测试；因此，性能测试工具必须有很好的调度能力，能够由一个主控机同时管理多台代理机完成性能测试任务，而不是由人去一台一台的代理机上操作来完成这个任务。

线性扩展能力

调度能力有好有坏，有些性能测试工具调度能力特别强，具备很好的线性扩展能力，当压力不够的时候能够通过增加压力机数量的方式来线性的增加吞吐量、并发量，从而实现目标。

稳定的并发能力

为什么是稳定的并发能力非常重要呢？

我们在实际性能测试当中往往并不是按照教科书上面写到的“单交易基准测试 -> 单交易负载 -> 混合交易基准 -> 混合交易负载 -> 稳定性测试 ” 这个套路来进行的，实际测试当中往往需要进行对比测试。比如说我应用程序换版前后对比，或者更换操作系统版本前后对比，或者一个数据库参数调节前调节后有一个对比。

对比测试当中的一个最重要的原则就是一次只调一个参数来对比前后的情况，如果我要调两个或者多个参数的话，如果发现前后性能差距很大，我很难判断是哪个参数导致的影响。因此，性能测试每次尽量只调一个参数，这个参数是什么呢？

这个参数就是应用程序的版本、操作系统的版本、数据库参数等等。并且前后对比的时候，要尽量保持其他要素不变。然而，其他性能指标不变是不可能的，那么就要控制住可控参数，观察不可控参数的变化。

业务吞吐量跟 CPU 利用率是最重要的参数之二，他们之间又有着直接的关系，对于大部分的交易系统来说，我的吞吐量上去的话， CPU 利用率也会随之上升，而 CPU 升高的话，吞吐量一般也会比较高。

我们的策略是对比两个场景在 CPU 利用率相同的情况下吞吐量的差异呢？还是对比吞吐量相同的情况下 CPU 利用率的差异呢？

这种情况下，我们的策略必须是对比吞吐量相同的情况下 CPU 利用率的差异，因为吞吐量我们是可以控制的，而 CPU 我们是不能控制的。使用工具发出来 100TPS 就是 100TPS ， 200TPS 就是 200TPS 。而 CPU 是操作系统和 CPU 共同控制的，它不在我们的控制能力范围。

通过上面分析我们看出，对比测试的原则下面“稳定”控制吞吐量是非常非常重要的。

因此，性能测试工具，必须能够“稳定”地控制吞吐量。那么什么程度算是稳定？从实际测试的经验来说，如果我的目标是每秒发送 100 笔业务，那么 98-102 这个范围之内是可以接受的，而实际上，大多数测试我们可以控制到 99-101 之间，也就是说误差范围在 1% 以内。如果超过 2% ，甚至超过 5% 的性能测试工具，我建议就要着手分析是不是工具的问题，或者分析你测试环境的问题（比如 CPU 利用率太高导致的波动）。

单机高吞吐能力

相同资源的 PC 机如果能发更多的业务压力，就能节省不少的环境资源，并且，压力机数量的减少，直接影响是维护这些工具的工作量减少了，整体测试效率提高了。

二次开发的能力

测试工具考虑另一个因素是二次开发的能力。我们经常会从 web 页面进行性能测试，因为 1 ）这个是最完整的业务流， 2 ）也是最容易实施的性能测试。然而大部分时候性能瓶颈或者说性能测试的核心不在那个页面上，而在后台系统服务器上面。高级的测试人员不想搭建前端的测试环境，第一，没有必要测，第二没有时间搭建，第三，没有资源分配。高级测试人员希望把更多的资源尽量分配到核心服务器上，并且直接对核心服务器进行压测。比如说我直接发文大批量的 SQL 查询语句到后台核心数据库服务器，或者批量的报文到后台服务器的 API 接口。

二、典型性能测试工具的对比和选择思路

市面上有一些流行或者不流行的性能测工具，我这里做一个简单介绍，这里举三个例子： IBM 的 RPT ， HP 的 Loadrunner ，开源的 JMeter 。

RPT

这里为什么举 IBM RPT 的例子呢，因为即使是专门做性能测试的人，也很少听说过 RPT 这个工具，在这里是把它当成一个反面例子来介绍的。

第一，有 license 的严格限制，而且这个 license 是没办法破解的，你需要把你测试的主控机的磁盘信息发送给 IBM ， IBM 根据这个信息返回给你一个 license 序列号，它和你的主控机绑死了，所以你是没办法破解的。

倒不是说建议大家去用什么破解版，而是说，有严格 license 限制的软件很难发展好。因为用户群体少，问题反馈少，社区不活跃，逐渐地恶性循环，这个软件就被淘汰了。

第二，最重要的一点， RPT 没有很好的线性扩展能力和调度能力。一台代理机能发出去每秒 200 笔业务，而两台三台四台代理机还是只能发出每秒 200 多笔业务，这个就是没有很好的线性扩展能力。

为什么会出现这种情况呢？因为所有待发送的数据它并不是放在各个代理机上的，而是放在主控机上，由主控机分发到各个代理去发送，这造成了很多不必要的网络消耗，并且主控机成了唯一的瓶颈。比如说我有 10 个代理机组成集群，他们发送的业务是有业务序号的，序号在集群内不能重复。 RPT 的做法就是生成序列号的工作仅由主控机来干。也就是说数据没有像大数据的方式分散在各个代理机上而是集权式的管理。

Loadrunner

Loadrunner 是目前商业软件当中最为流行的。为什么会流行呢，首先它的 license 是可以破解的，这就导致用户数量庞大，用户也喜欢用，并且用它发送很高的压力（而 IBM RPT 的 license 和并发数是相关的，花钱少是没法设置高并发的）。这个原因非常重要，导致了用户和软件之间的正反馈，促使 Loadrunner 不断地改进，最后成为一个流行的工具，反观 RPT 有严格的 license 限制，用户特别少，也没什么反馈，最后恶性循环后在市场上消失了。

JMeter

JMeter 作为开源领域最火爆的一款性能测试工具，在互联网公司里面用的比较广，现在在金融这种领域的公司也用的比较广。但是吞吐量控制的不是很稳定。

我这里举一个如何做后台性能测试的例子。我要给一个数据库服务器施加查询压力，向这台数据库发送一万次某个查询语句。正常的做法是什么呢？写三个函数：

第一个函数 init ：创建数据库的连接，并准备一个 SQL 语句。

第二函数 action ：负责给 SQL 语句填入参数，真正的去做查询的动作，反复地去做 1 万遍。

第三函数 end ：做一些清理工作，断开与数据库的连接。

这三个函数中，第一个函数跟第三个函数都是只做一遍，中间的 action 函数是迭代了一万遍。

事实上像 Loadrunner 和 JMeter 这样的性能工具也的确是这么实现的，而遗憾的是 RPT 就不是这么实现的。 RPT 怎么实现呢？我的 init 函数、 action 函数、 end 函数对于每一次交易都要执行一遍，如果执行 1 万次查询，这三个函数一共执行了 3 万次，大大降低了单机执行效率。也就是说， RPT 除了线性扩展能力特别差，即使是在单机上面的性能也是非常差。相同资源的 PC 机资源（比如说 4C4G 的 PC ）一秒钟能发 200 笔业务，而 RPT 就只能发 100 笔业务，非常浪费性能测试环境的资源，并且，不仅仅是浪费资源的问题，而且你的测试代理机一旦多起来维护管理工作将成倍增长。

结论

在选择性能测试工具的时候一定要选择流行的性能测试工具（ license 限制不严格的工具）。如果你的测试领域比较特殊，流行的测试工具不能满足你的需求，而要选择一个细分领域的、比较专业的性能测试工具或者要自己开发一个性能测试工具的话，文中前面介绍到的调度能力、线性扩展能力、稳定的并发能力、二次开发能力、单机高吞吐能力就是考察的重点。