JMeter、Locust和Gatling的并发模型对比

起因

最近不少公众号和在线课程都在讨论性能测试和性能工程，但是鲜有涉及开源性能测试工具的比较与选择。几年前我就写过一篇介绍Gatling的文章《性能测试之新一代服务器性能测试工具Gatling》，里面简单的比较了JMeter和Gatling自身性能和开发形式。现在最为常用的三款开源免费性能测试工具/框架就是JMeter，Locust和Gatling。

为了帮助大家更好地理解和选择它们，我将从并发模型角度来介绍并比较它们。

并发

说到并发，我们首先想到的就是服务端系统的并发模型，现在常见的并发模型有多线程模型，事件循环模型，Actor模型和CSP模型等。为了能测试服务器系统的并发能力，性能测试工具也需要支持与之相应的并发发包能力。而充分了解性能测试工具的并发模型，可以更好地帮助你选择适合自己的性能测试工具。

JMeter，Locust和Gatling选择了三种不同的并发模型，这个应该是和开发者当时的技术背景，业务需求，资源情况等密切相关的。所以没有必要去探究当时作者为什么要选择这个模型，但是可以尝试去理解这些不同模型的特点，从而选择到适合自己的模型。

JMeter使用的是多线程模型，Locust使用的是事件循环模型，而Gatling使用的是Actor模型，最近又有一个后起之秀K6，它则使用的是CSP模型。 

并行和并发是完全不同的两个概念，简单说并行是操作系统和CPU的一种能力，而并发是应用程序的一种能力。如果性能测试工具支持多线程或者多进程，并且运行的操作系统支持并行以及CPU是多核的情况下，其发包能力能大大增强。但是这样的条件比较苛刻，所以这里就不做深入探讨。

比较

JMeter

JMeter是三个工具中最早发布的性能测试工具，由于早期性能测试的需求并不十分复杂，并且对于并发性能的要求也不是很高，所以JMeter使用了当时最为成熟的并发模型——多线程模型（Threads）和Java语言来开发。

这种模型的特点就是，重度依赖于开发语言和操作系统对于多线程的支持，如果语言和操作系统层面对于多线程的支持不好，就会导致这种并发模型出现问题。

其次多线程切换的时候资源消耗比较多，所以和另外两个轻量级的并发模型相比，在同等资源的情况下，产生的有效并发数量会小很多。

最后多线程也相对容易产生错误，比如死锁，共享数据错乱等，所以JMeter使用界面的方式也是尽可能地减少了由于二次开发导致的这类错误。

其优势就是可以在操作系统支持的情况下，使用到多核处理器的多个核。但是随着性能测试需求的增多，JMeter为了能满足更多的需求，也在不停地更新功能和增加其插件，比如支持分布式来解决性能不足的问题，支持更多的扩展脚本来满足自定义需求等等。但是其基础并发模型一直沿用多线程模型，导致并发性能没有办法进一步提升，估计在未来可以预见的很长一段时间之内是不会改变的。

Locust

Gatling

总结

👇👇👇扫描下图二维码，免费报名直播。PC端报名请点击「阅读原文」，推荐扫描二维码。