聊聊 ab 和 jmeter 的并发模型

作者：烧鸡太子爷

来源：恒生LIGHT云社区

简介

前面一篇文章里（详见 很好用的压测工具 - Apache Bench工具）有讲到因为项目需要，在对比了jmeter和ab以后使用了ab测试工具来测试服务器的性能，今天我们就来讲讲ab和jmter的并发模型，就是他如何保证能够模拟高并发客户端的场景的。

其实我们一说到并发，我们首先想到的就是服务端系统的并发模型，而为了能测试到这样的服务器系统的并发能力，性能测试工具也需要支持与之相应的并发包能力。而充分了解性能测试工具的并发模型，可以更好地帮助你选择适合自己的性能测试工具。其中 JMeter&&ab，Locust 和 Gatling 就选择了三种不同的发模型，这个应该是和开发者当时的技术背景，业务需求，资源情况等密切相关的。所以没必要去探究当时作者为什么要选择这个模型，但是可以尝试去理解这些不同模型的特点，从而选择到适合自己的模型。今天我们主要讲的jmeter和ab的模型，其他的我们后面有时间在做分析。

并发模型的相关概念

同步、异步、阻塞、非阻塞

要讲并发模型，我们绕不开以下四个名词：

• 同步（Synchronous）
• 异步（Asynchronous）
• 阻塞 （Blocking)
• 非阻塞（Nonblocking）

目前你能通过百度找到的、能查找到很多关于这些的解释，每个人都会有自己的一些理解。我这边不班门弄斧地来解释这四个词的差别，只是提一些大部分资料中忽视的点：

• 要区分同步、异步，必须讲清楚其所处的层，比如框架、用户空间、内核、IO模型
• 同步调用发起后，没有得到结果不返回，那么毫无疑问就是被阻塞了
• 异步调用发起后直接返回，毫无疑问，这个进程没有被阻塞

在Operating System Concepts [9th Edition]（操作系统概念第9版本）该书中描述对进程间通信进行了一些描述

也就是说，站在进程通信纬度上来看，阻塞、非阻塞与同步、异步是同义词，但是需要区分发送方、接收方：

• 阻塞发送
• 非阻塞发送
• 阻塞接受
• 非阻塞接受

上述不同类型的发送方法和不同类型的接收方法可以自由组合

另外，我们还知道Linux有五种I/O模型：

• 阻塞式IO（Blocking I/O）
• 非阻塞式IO（Nonblocking I/O）

• IO复用（I/O multiplexing）

  • select
  • poll
  • epoll
• 信号驱动式IO（Signal Driver I/O）

• 异步IO（Asynchronous I/O）

  • AIO

除了Asynchronous I/O以外，其余4种都是同步IO

多进程/多线程

做开发的兄弟应该都能理解：

• 多进程：同一时刻执行多个程序。如，你打开电脑运行微信，钉钉，chrome等就是多进程（进程列表里能看到多个程序在运行）；
• 多线程：同一时刻执行多个线程。如，用chrome一边看新闻，一边听歌，一边看下载（只启一个浏览器进程，运行多线程任务）；

了解上面的概念以后呢，然后我们再来讲讲ab和jmeter的并发模型

基于多线程并发的ab、jmeter

ab、JMeter分别是用C、Java开发的、基于多线程并发模型的压测工具，也是目前最流行的开源压测工具，两者的工作原理类似，如下图：

• 不管ab还是JMeter，其所谓的虚拟用户(vuser)就是对应一个线程
• 在单个线程中，每个请求（query）都是同步调用的，下一个请求要等待前一个请求完成才能进行

• 一个请求（query）分成三部分：

  • send - 施压端发送开始，直到承压端接收完成
  • wait - 承压端接收完成开始，直至业务处理结束
  • recv - 承压端返回数据，直至施压端接收完成
• 同一线程中连续的两个请求之间存在等待时间这种概念，即图中的空白处

总的来说，多线程模型的优劣势总结有如下 ：

（1）重度依赖于开发语言和操作系统对多线程的支持

（2）多线程切换的时候资源消耗比较多，在同等资源的情况下，产生的有效并发数量小；

（3）多线程也相对容易产生错误，比如死锁，共享数据错乱；

（4）可以通过丰富的界面来减少二次开发导致上面的一些错误；

（5）通过扩展开发和插件实现分布式来满足并发量的不足；

（6）多线程的应用技术比较成熟，未来相当长时间，还会继续应用于很多性能测试工具。

（7）从应用角度来看，基于多线程的并发模型，往往需要设置最大并发数参数，而如果压测场景需要不断往上加压，那这类工具其实挺难应付的

参考

• [操作系统概念第9版]
• <聊聊ab、wrk、JMeter、Locust这些压测工具的并发模型差别>