聊聊 ab 和 jmeter 的并发模型测试测试工具ab测试

作者：烧鸡太子爷
来源：恒生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）多线程的应用技术比较成熟，未来相当长时间，还会继续应用于很多性能测试工具。
【聊聊 ab 和 jmeter 的并发模型】（7）从应用角度来看，基于多线程的并发模型，往往需要设置最大并发数参数，而如果压测场景需要不断往上加压，那这类工具其实挺难应付的
参考