> 作者：燒雞太子爺
>
> 來源：[恆生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 和 jmeter 的併發模型

相關文章