性能：性能测试工具面面观

最新推荐文章于 2024-11-07 16:00:00 发布

OceanStar的学习笔记

最新推荐文章于 2024-11-07 16:00:00 发布

阅读量327

点赞数

分类专栏：计算机理论与基础文章标签：测试工具

原文链接：https://time.geekbang.org/

版权

计算机理论与基础专栏收录该内容

310 篇文章

订阅专栏

常见性能测试工具

在这里插入图片描述

对市场的占有率来说，JMeter 和 LoadRunner 以绝对的优势占据前两名，同时 JMeter 又以绝对的优势占据第一名

这是全球范围近 5 年 JMeter 和 LoadRunner 热度（红色线是 LoadRunner，蓝色线是JMeter
在这里插入图片描述
从上面的比对来看，我们可以很容易发现，近五年来，LoadRunner 就一直在走下坡路，而 JMeter 一直处在上升的趋势。

JMeter 和 LoadRunner 的历史兴衰

先说说 LoadRunner 吧，应该说，LoadRunner 的历史，就是一段悲惨的回忆。

2006 年11 月份以前，在 Mercury 时代，LoadRunner 由于市场策略和工具优势很快占了第一名，势头很猛。当时还有另一个同样功能的工具 Silk Performer，被打压得几乎抬不起头来。
06 年以后，Mercury 以 45 亿美元被 HP 收购，包括 QC、QTP 等工具。但从那之后，LoadRunner 的体积就在飞速膨胀，8.1 的 LoadRunner 只有 600M 左右，经历了几个版本的迭代，LoadRunner 成功膨胀到 4 个 G，并在后面规划performance center，在各地做质量中心。HP 这一步步走得理直气壮，把市场折腾没了。
现在 LoadRunner 如果想装到一台压力机上，都是很吃力的事情

而拥有同样竞品工具 Silk Performer、Silk Test 和 Silk Test Manager 的 Segue 公司，同年仅以 1 亿美元被另一个企业 Borland 收购。3 年之后，Borland 连同自己，以 7500 万美元卖给了 MicroFocus。

至此，MicroFocus 同时拥有了 LoadRunner 和 Silk Performer。但可惜的是，这也照样干不过一个无心插柳柳成荫的开源工具 JMeter。

JMeter 的历史，可以说是屌丝逆袭的典型案例。

1998 年，Apache 基金会的 StefanoMazzocchi 是它最初的开发者，当时他只是为了测试 Apache JServlet 的性能（这个项目后来被 Tomcat 取代），后来 JMeter 被重构，又被用来测试 Tomcat。
其实一开始，JMeter 的功能很简单。但是 Apache Tomcat 的势头实在是阻挡不住，再加上 Java 市场覆盖率实在是太高了，而 JMeter 做为一个开源免费的 Java 压力工具，有着众多的contributors，顶着 Apache 的大旗，想失败都难。
就像 ab 工具是为了测试 Apache HTTP server 一样，JMeter 应该说是和 Apache Tomcat 一起成长的。

与此同时，还有另一个 Java 开源工具 The Grinder，这个工具的主要贡献者是 Philip Aston、Calum Fitzgerald。

当时有一个开源测试平台叫 NGrinder，是韩国公司 NHN 开源的。
有很多所谓企业内部自研发的性能测试平台，就是从 NGrinder 借鉴来的，而 NGrinder 就是以 The Grinder 为基础开发的。
可惜的是，The Grinder 没有 Apache 这样的平台，作为一个很优秀的工具，它的维护更新还是不够快，不过 NGrinder 也给它带来了一定的荣耀。

到现在为止，JMeter 还没有一个非常成熟的云测试平台支撑它，只有一些商业公司改动，加一些管理和项目属性，做为企业内部平台使用。还有一些企业把 JMeter 改造成商业产品，加上云基础架构的管理功能，就成了一套完整的商业平台，再加上炫丽的操作页面，棒棒的，有没有？

那么你有没有想过，为什么没有以 JMeter 为基础的开源云测试平台呢？难道 JMeter 的热爱者看不到云测试平台的价值吗？在我看来，做为性能测试工具，它实在是没有必要做成一个开源的测试平台，因为轮子就是轮子，要装成什么样的车就自己装吧。要是再换个角度来说，性能测试真的有必要用平台吗？

使用性能测试工具的误区在哪

工具应该如何用，完全取决于用的人，而不是工具本身

压测工具也好，压测平台也好，都没有一个工具可以直接告诉你瓶颈在哪里，能告诉你的只是数据是什么。分析只有靠自己，在这个过程中，我们也会用到很多的分析剖析工具，用这些工具的人也都会知道，工具也只提供数据，不会告诉你瓶颈点在哪里。

关于剖析工具的，我们后面再写。本篇重点在压测工具上。

有人说 JMeter BIO 有问题，应该用 AIO；有人说，压测工具没有后端系统性能监控数据，应该加一个监控插件。像 JMeter 中就有一个插件叫 perfmon，把后端的系统资源拉到JMeter 的界面中来看。在这一点上，LoadRunner 老早就做过了，并且在之前的版本中还有个专门的组件叫 tuning，目的就是把后端所有的系统、应用、数据库都配置到一个架构图中，压力一发起，就把有问题的组件标红。想法很好，可是这个功能为什么没有被广泛使用？当然，后面被 HP 收购后，这和 HP 的市场策略有关，但是在收购前的 Mercury 时代，该功能也没有被广泛使用。

我们从实际的生产场景来看，压测工具模拟的是真实用户，而监控在哪里，在运维后台里，数据的流行都不一样。如果你使用压测工具的同时，也把它做为收集性能监控数据的工具，本身流量就会冲突。

所以在压测工具中同时收集监控计数器，就是不符合真实场景的。
这样压测平台就有出现的必要了，我们可以看到出现了五花八门的压测平台，也会有后端监控数据的曲线，乍看起来，就两个字：全面！

可是，同样也没有告诉你瓶颈在哪里。