> 作者：烧鸡太子爷
>
> 来源：[恒生LIGHT云社区](https://developer.hs.net/thread/1614)

## 简介

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

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

## 并发模型的相关概念

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

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

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

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

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

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

![1.jpg](https://developer.hs.net/storage/attachments/2021/11/22/S5iHA9HWc6ayRqggRFH1P8tHxSMQJoQjBLWSkmI9_thumb.jpg "3828")

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

* 阻塞发送
* 非阻塞发送
* 阻塞接受
* 非阻塞接受

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

另外，我们还知道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一边看新闻，一边听歌，一边看下载（只启一个浏览器进程，运行多线程任务）；

![2.jpg](https://developer.hs.net/storage/attachments/2021/11/22/p8jLKnXDq6rjculVLPr59ra8xHqDJwWdNucaAKFI_thumb.jpg "3829")

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

## 基于多线程并发的ab、jmeter

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

![3.png](https://developer.hs.net/storage/attachments/2021/11/22/3oVQ01zCSUb4HHzExnZWjOXW2JiT4HDhTBF8bONh_thumb.png "3830")

* 不管ab还是JMeter，其所谓的虚拟用户(vuser)就是对应一个线程
* 在单个线程中，每个请求（query）都是同步调用的，下一个请求要等待前一个请求完成才能进行
* 一个请求（query）分成三部分：
  * send - 施压端发送开始，直到承压端接收完成
  * wait - 承压端接收完成开始，直至业务处理结束
  * recv - 承压端返回数据，直至施压端接收完成
* 同一线程中连续的两个请求之间存在等待时间这种概念，即图中的空白处

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

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

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

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

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

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

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

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

## 参考

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

ITPub博客

聊聊 ab 和 jmeter 的并发模型

最新文章