異步壓力測試探索：什麼是異步非阻塞

Real-time web features require a long-lived mostly-idle connection per user. In a traditional synchronous web server, this implies devoting one thread to each user, which can be very expensive.

Web系統的實時性要求，爲每一個用戶保持一個鏈接，這些鏈接大多時間是空閒的。在傳統的同步web服務器中，便是爲每一個用戶分配一個線程，這種作法至關耗費資源。

 

那麼什麼是同步/異步、阻塞/非阻塞呢？

異步（Asynchronous）和非阻塞（non-blocking）是緊密相關的兩個術語，也常常被不加區分使用。但實際它們是不一樣的概念。

當一個方法在返回前等待某件事情，那麼它就被阻塞了。引發阻塞的事情能夠是network，能夠是IO，也能夠是CPU。實際上，任何一個方法都或多或少的被阻塞，由於只要運行就須要CPU。

而咱們常說的阻塞/非阻塞，一般是從某一個方面來看的。好比非阻塞的http請求（發送即返回，不等待響應），在域名解析時仍然是阻塞的，只不過這類阻塞從總體上來看影響是很是小的。

而異步說的是，一個方法在執行結束前就返回了，通常會在後臺產生一些工做並在將來某一時刻觸發一些動做。與之相對應的同步，就是說在方法返回前，要把全部的事情作完。

 

好吧，仍是以爲很難區分。。。不過這不重要，知道是這麼一回事就能夠了。

 

來一個例子：

餐廳來了10個顧客，爲了提供最佳消費體驗，不讓顧客等待，爲每一個顧客分配一個服務員。服務員給顧客安排好座位，把菜單交給顧客，而後在一邊等待顧客點餐。點完餐後把訂單交給廚房，而後在廚房等待大廚烹飪。菜作好後，將菜送到桌上，而後在桌旁靜靜的看着顧客吃。。。

這就是同步，爲了保證「實時」的服務，須要有一個專門的人員時刻等待。

有人說了，這尼瑪不是有病麼！哪一個餐廳這麼幹？但是傳統的web服務器就是這樣的呢，好比apache。

 

現實中的餐廳爲了節省成本，固然不會這麼作，也許兩個服務員就足夠了。給新進來的顧客安排好座位，菜單交給他，而後就能夠去忙活其餘的顧客了。等顧客點好菜喊一聲，趕忙衝過來下單。。。

這就是前文所說的異步方式，服務員不須要等待顧客完成所有任務，就「返回」了。

那有這種方式的web服務器麼？固然有了，也是近年來的新趨勢，如nginx、tornado等。

 

又有人說了，這和咱們的主題壓力測試又有什麼關係呢？

咱們以往所作的壓力測試，通常是要經過一些工具來模擬壓力（多用戶），好比LoadRunner, Jmeter等，也都是採用這種同步的方式。測試工程師負責寫腳原本定義「一個」用戶的行爲，工具會啓動多個線程執行腳本，每一個線程只負責本身的腳本（一個用戶）。

在測試腳本中，描述了一個用戶的典型操做。好比訪問一個網址，提交一些數據，等待返回的響應，而後可能還要休息一段時間（ThinkTime）再作下一次操做。

實際上，一個線程在執行腳本的過程當中，絕大多數時間都是在等待的，等待服務器響應，以及主動的sleep模擬真實用戶的操做間隔。

 

能夠看到，同步方式最大的問題就是浪費資源。一萬個用戶須要一萬個線程，一萬個線程須要幾臺機器才能運行呢？

 

既然這麼多線程都在等待，難道不能用更少的線程麼？在一個用戶等待的時間，去處理其餘用戶的事情？

這正是這個系列文章要探索的內容——採用異步的方式來作壓力測試。

敬請期待！

 

ps.

時隔三年，再一次更新博客。

這三年，經歷了創業團隊，也懷疑過將來的方向。

最終在給本身放了半年長假後，選擇迴歸這個領域。