服務端I/O效能大比拼：Node、PHP、Java、Go

原文：Server-side I/O Performance: Node vs. PHP vs. Java vs. Go
作者：BRAD PEABODY
翻譯：雁驚寒

摘要：本文首先簡單介紹了I/O相關的基礎概念，然後橫向比較了Node、PHP、Java、Go的I/O效能，並給出了選型建議。以下是譯文。

瞭解應用程式的輸入/輸出（I/O）模型能夠更好的理解它在處理負載時理想情況與實際情況下的差異。也許你的應用程式很小，也無需支撐太高的負載，所以這方面需要考慮的東西還比較少。但是，隨著應用程式流程量負載的增加，使用錯誤的I/O模型可能會導致非常嚴重的後果。

在本文中，我們將把Node、Java、Go和PHP與Apache配套進行比較，討論不同語言如何對I/O進行建模、每個模型的優缺點，以及一些基本的效能評測。如果你比較關心自己下一個Web應用程式的I/O效能，本文將為你提供協助。 I/O基礎：快速回顧一下

要瞭解與I/O相關的因素，我們必須首先在作業系統層面上瞭解這些概念。雖然不太可能一上來就直接接觸到太多的概念，但在應用的運行過程中，不管是直接還是間接，總會遇到它們。細節很重要。 系統調用

首先，我們來認識下系統調用，具體描述如下：

應用程式請求作業系統核心為其執行I/O操作。

“系統調用”是指程式請求核心執行某些操作。其實現細節因作業系統而異，但基本概念是相同的。在執行“系統調用”時，將會有一些控製程序的特定指令轉移到核心中去。一般來說，系統調用是阻塞的，這意味著程式會一直等待直到核心返回結果。

核心在物理裝置（磁碟、網卡等）上執行底層I/O操作並回複系統調用。在現實世界中，核心可能需要做很多事情來滿足你的請求，包括等待裝置準備就緒、更新其內部狀態等等，但作為一名應用程式開發人員，你無需關心這些，這是核心的事情。

阻塞調用與非阻塞調用

我在上面說過，系統調用一般來說是阻塞的。但是，有些調用卻屬於“非阻塞”的，這意味著核心會將請求放入隊列或緩衝區中，然後立即返回而不等待實際I/O的發生。所以，它只會“阻塞”很短的時間，但排隊需要一定的時間。

為了說明這一點，下面給出幾個例子（Linux系統調用）：

read()是一個阻塞調用。我們需要傳遞一個檔案控制代碼和用於儲存資料的緩衝區給它，當資料儲存到緩衝區之後返回。它的優點是優雅而又簡單。

epoll_create()、epoll_ctl()和epoll_wait()可用於建立一組控制代碼進行監聽，添加/刪除這個組中的控制代碼、阻塞程式直到控制代碼有任何的活動。這些系統調用能讓你只用單個線程就能高效地控制大量的I/O操作。這些功能雖然非常有用，但使用起來相當複雜。

瞭解這裡的時間差的數量級非常重要。如果一個沒有最佳化過的CPU核心以3GHz的頻率運行，那麼它可以每秒執行30億個周期（即每納秒3個周期）。一個非阻塞的系統調用可能需要大約10多個周期，或者說幾個納秒。對從網路接收資訊的調用進行阻塞可能需要更長的時間，比如說200毫秒（1/5秒）。比方說，非阻塞調用花了20納秒，阻塞調用花了200,000,000納秒。這樣，進程為了阻塞調用可能就要等待1000萬個周期。

核心提供了阻塞I/O（“從網路讀取資料”）和非阻塞I/O（“告訴我網路連接上什麼時候有新資料”）這兩種方法，並且兩種機制阻塞調用進程的時間長短完全不同。 調度

第三個非常關鍵的事情是當有很多線程或進程開始出現阻塞時會發生什麼問題。

對我們而言，線程和進程之間並沒有太大的區別。而在現實中，與效能相關的最顯著的區別是，由於線程共用相同的記憶體，並且每個進程都有自己的記憶體空間，所以單個進程往往會佔用更多的記憶體。但是，在我們談論調度的時候，實際上講的是完成一系列的事情，並且每個事情都需要在可用的CPU核心上獲得一定的執行時間。如果你有8個核心來運行300個線程，那麼你必須把時間分區，這樣，每個線程才能獲得屬於它的時間片，每一個核心運行很短的時間，然後切換到下一個線程。這是通過“環境切換”完成的，可以讓CPU從一個線程/進程切換到下一個線程/進程。

這種環境切換有一定的成本，即需要一定的時間。快的時候可能會小於100納秒，但如果實現細節、處理器速度/架構、CPU緩衝等軟硬體的不同，花個1000納秒或更長的時間也很正常。

線程（或進程）數量越多，則環境切換的次數也越多。如果存在成千上萬的線程，每個線程都要耗費幾百納秒的切換時間的時候，系統就會變得非常慢。

然而，非阻塞調用實質上告訴核心“只有在這些串連上有新的資料或事件到來時才調用我”。這些非阻塞調用可有效地處理大I/O負載並減少環境切換。

值得注意的是，雖然本文舉得例子很小，但資料庫訪問、外部緩衝系統（memcache之類的）以及任何需要I/O的東西最終都會執行某種類型的I/O調用，這跟樣本的原理是一樣的。

影響項目中程式設計語言選擇的因素有很多，即使你只考慮效能方面，也存在很多的因素。但是，如果你擔心自己的程式主要受I/O的限制，並且效能是決定項目成功或者失敗的重要因素，那麼，下文提到的幾點建議就是你需要重點考慮的。 “保持簡單”：PHP

早在上世紀90年代，有很多人穿著Converse鞋子使用Perl編寫CGI指令碼。然後，PHP來了，很多人都喜歡它，它使得動態網頁的製作更加容易。

PHP使用的模型非常簡單。雖然不可能完全相同，但一般的PHP伺服器原理是這樣的：

使用者瀏覽器發出一個HTTP請求，請求進入到Apache web伺服器中。 Apache為每個請求建立一個單獨的進程，並通過一些最佳化手段對這些進程進行重用，從而最大限度地減少原本需要執行的操作（建立進程相對而言是比較慢的）。

Apache調用PHP並告訴它運行磁碟上的某個.php檔案。

PHP代碼開始執行，並阻塞I/O調用。你在PHP中調用的file_get_contents()，在底層實際上是調用了read()系統調用並等待返回的結果。

<?php// blocking file I/O$file_data = file_get_contents(‘/path/to/file.dat’);// blocking network I/O$curl = curl_init('http://example.com/example-microservice');$result = curl_exec($curl);// some more blocking network I/O$result = $db->query('SELECT id, data FROM examples ORDER BY id DESC limit 100');?>

與系統的整合示意圖是這樣的：

很簡單：每個請求一個進程。 I/O調用是阻塞的。那麼優點呢。簡單而又有效。缺點呢。如果有20000個用戶端並發，伺服器將會癱瘓。這種方法擴充起來比較難，因為核心提供的用於處理大量I/O（epoll等）的工具並沒有充分利用起來。更糟糕的是，為每個請求運行一個單獨的進程往往會佔用大量的系統資源，尤其是記憶體，這通常是第一個耗盡的。

*注意：在這一點上，Ruby的情況與PHP非常相似。 多線程：Java

所以，Java就出現了。而且Java在語言中內建了多線程，特別是在建立線程時非常得棒。

大多數的Java Web伺服器都會為每個請求啟動一個新的執行線程，然後在這個線程中調用開發人員編寫的函數。

在Java Servlet中執行I/O往往是這樣的：

publicvoiddoGet(HttpServletRequest request,    HttpServletResponse response) throws ServletException, IOException{    // blocking file I/O    InputStream fileIs = new FileInputStream("/path/to/file");    // blocking network I/O    URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();    InputStream netIs = urlConnection.getInputStream();    // some more blocking network I/Oout.println("...");}

由於上面的doGet方法對應於一個請求，並且在自己的線程中運行，而不是在需要有獨立記憶體的單獨進程中運行，所以我們將建立一個單獨的線程。每個請求都會得到一個新的線程，並在該線程內部阻塞各種I/O操作，直到請求處理完成。應用會建立一個線程池以最小化建立和銷毀線程的成本，但是，成千上萬的串連意味著有成千上萬的線程，這對於調度器來說並不件好事情。

值得注意的是，1.4版本的Java（1.7版本中又重新做了升級）增加了非阻塞I/O調用的能力。雖然大多數的應用程式都沒有使用這個特性，但它至少是可用的。一些Java Web伺服器正在嘗試使用這個特性，但絕大部分已經部署的Java應用程式仍然按照上面所述的原理進行工作。

Java提供了很多在I/O方面開箱即用的功能，但如果遇到建立大量阻塞線程執行大量I/O操作的情況時，Java也沒有太好的解決方案。 把非阻塞I/O作為頭等大事：Node

在I/O方面表現比較好的、比較受使用者歡迎的是Node.js。任何一個對Node有簡單瞭解的人都知道，它是“非阻塞”的，並且能夠高效地處理I/O。這在一般意義上是正確的。但是細節和實現的方式至關重要。

在需要做一些涉及I/O的操作的時候，你需要發出請求，並給出一個回呼函數，Node會在處理完請求之後調用這個函數。

在請求中執行I/O操作的典型代碼如下所示：

http.createServer(function(request, response) {    fs.readFile('/path/to/file', 'utf8', function(err, data) {        response.end(data);    });});

如上所示，這裡有兩個回呼函數。當請求開始時，第一個函數會被調用，而第二個函數是在檔案資料可用時被調用。

這樣，Node就能更有效地處理這些回呼函數的I/O。有一個更能說明問題的例子：在Node中調用資料庫操作。首先，你的程式開始調用資料庫操作，並給Node一個回呼函數，Node會使用非阻塞調用來單獨執行I/O操作，然後在請求的資料可用時調用你的回呼函數。這種對I/O調用進行排隊並讓Node處理I/O調用然後得到一個回調的機制稱為“事件迴圈”。這個機制非常不錯。

然而，這個模型有一個問題。在底層，這個問題出現的原因跟V8 JavaScript引擎（Node使用的是Chrome的JS引擎）的實現有關，即：你寫的JS代碼都運行在一個線程中。請思考一下。這意味著，儘管使用高效的非阻塞技術來執行I/O，但是JS代碼在單個線程操作中運行基於CPU的操作，每個代碼塊都會阻塞下一個代碼塊的運行。有一個常見的例子：在資料庫記錄上迴圈，以某種方式處理記錄，然後將它們輸出到用戶端。下面這段代碼展示了這個例子的原理：

var handler = function(request, response) {    connection.query('SELECT ...', function(err, rows) {if (err) { throw err };        for (var i = 0; i < rows.length; i++) {            // do processing on each row        }        response.end(...); // write out the results    })};

雖然Node處理I/O的效率很高，但是上面例子中的for迴圈在一個主線程中使用了CPU周期。這意味著如果你有10000個串連，那麼這個迴圈就可能會佔用整個應用程式的時間。每個請求都必須要在主線程中佔用一小段時間。

這整個概念的前提是I/O操作是最慢的部分，因此，即使串列處理是不得已的，但對它們進行有效處理也是非常重要的。這在某些情況下是成立的，但並非一成不變。

另一點觀點是，寫一堆嵌套的回調很麻煩，有些人認為這樣的代碼很醜陋。在Node代碼中嵌入四個、五個甚至更多層的回調並不罕見。

又到了權衡利弊的時候了。如果你的主要效能問題是I/O的話，那麼這個Node模型能幫到你。但是，它的缺點在於，如果你在一個處理HTTP請求的函數中放入了CPU處理密集型代碼的話，一不小心就會讓每個串連都出現擁堵。 原生無阻塞：Go

在介紹Go之前，我透露一下，我是一個Go的粉絲。我已經在許多項目中使用了Go。

讓我們看看它是如何處理I/O的吧。 Go語言的一個關鍵特性是它包含了自己的調度器。它並不會為每個執行線程對應一個作業系統線程，而是使用了“goroutines”這個概念。Go運行時會為一個goroutine分配一個作業系統線程，並控制它執行或暫停。Go HTTP伺服器的每個請求都在一個單獨的Goroutine中進行處理。

發送器的工作原理如下所示：

實際上，除了回調機制被內建到I/O調用的實現中並自動與調度器互動之外，Go運行時正在做的事情與Node不同。它也不會受到必須讓所有的處理代碼在同一個線程中啟動並執行限制，Go會根據其發送器中的邏輯自動將你的Goroutine映射到它認為合適的作業系統線程中。因此，它的代碼是這樣的：

func ServeHTTP(w http.ResponseWriter, r *http.Request) {    // the underlying network call here is non-blocking    rows, err := db.Query("SELECT ...")    for _, row := range rows {        // do something with the rows,// each request in its own goroutine    }    w.Write(...) // write the response, also non-blocking}

如上所示，這樣的基本代碼結構更為簡單，而且還實現了非阻塞I/O。

在大多數情況下，這真正做到了“兩全其美”。非阻塞I/O可用於所有重要的事情，但是代碼卻看起來像是阻塞的，因此這樣往往更容易理解和維護。 剩下的就是Go發送器和OS發送器之間的互動處理了。這並不是魔法，如果你正在建立一個大型系統，那麼還是值得花時間去瞭解它的工作原理的。同時，“開箱即用”的特點使它能夠更好地工作和擴充。

Go可能也有不少缺點，但總的來說，它處理I/O的方式並沒有明顯的缺點。 效能評測

對於這些不同模型的環境切換，很難進行準確的計時。當然，我也可以說這對你並沒有多大的用處。這裡，我將對這些伺服器環境下的HTTP服務進行基本的效能評測比較。請記住，端到端的HTTP請求/響應效能涉及到的因素有很多。

我針對每一個環境都寫了一段代碼來讀取64k檔案中的隨機位元組，然後對其運行N次SHA-256散列（在URL的查詢字串中指定N，例如.../test.php?n=100）並以十六進位列印結果。我之所以選擇這個，是因為它可以很容易運行一些持續的I/O操作，並且可以通過受控的方式來增加CPU使用率。

首先，我們來看一些低並發性的例子。使用300個並發請求運行2000次迭代，每個請求雜湊一次（N=1），結果如下：

Times是完成所有並發請求的平均毫秒數。越低越好。

從單單這一張圖中很難得到結論，但我個人認為，在這種存在大量串連和計算的情況下，我們看到的結果更多的是與語言本身的執行有關。請注意，“指令碼語言”的執行速度最慢。

但是如果我們將N增加到1000，但仍然是300個並發請求，即在相同的負載的情況下將散列的迭代次數增加了1000倍（CPU負載明顯更高），會發生什麼情況呢：

Times是完成所有並發請求的平均毫秒數。越低越好。

突然之間，由於每個請求中的CPU密集型操作相互阻塞，Node的效能顯著下降。有趣的是，在這個測試中，PHP的效能變得更好了（相對於其他），甚至優於Java。 （值得注意的是，在PHP中，SHA-256的實現是用C語言編寫的，但執行路徑在這個迴圈中花費了更多的時間，因為我們這次做了1000次雜湊迭代）。

現在，讓我們試試5000個並發串連（N=1） 。不幸的是，對於大多數的環境來說，失敗率並不明顯。我們來看看這個圖表中每秒處理的請求數，越高越好：

每秒處理的請求數，越高越好。

這個圖看起來跟上面的不太一樣。我猜測，在較高的串連數量下，PHP + Apache中產生新進程和記憶體的申請似乎成為了影響PHP效能的主要因素。 很顯然，Go是這次的贏家，其次是Java，Node，最後是PHP。

雖然涉及到整體輸送量的因素很多，而且應用程式和應用程式之間也存在著很大的差異，但是，越是瞭解底層的原理和所涉及的權衡問題，應用程式的表現就會越好。 總結

綜上所述，隨著語言的發展，處理大量I/O大型應用程式的解決方案也隨之發展。

公平地說，PHP和Java在web應用方面都有可用的非阻塞I/O的實現。但是這些實現並不像上面描述的方法那麼使用廣泛，並且還需要考慮維護上的開銷。更不用說應用程式的代碼必須以適合這種環境的方式來構建。

我們來比較一下幾個影響效能和易用性的重要因素：

語言	線程與進程	非阻塞I/O	便於使用
PHP	進程	否	-
Java	線程	有效	需要回調
Node.js	線程	是	需要回調
Go	線程 (Goroutines)	是	無需回調

因為線程會共用相同的記憶體空間，而進程不會，所以線程通常要比進程的記憶體效率高得多。在上面的列表中，從上往下看，與I/O相關的因素一個比一個好。所以，如果我不得不在上面的比較中選擇一個贏家，那肯定選Go。

即便如此，在實踐中，選擇構建應用程式的環境與你團隊對環境的熟悉程度以及團隊可以實現的整體生產力密切相關。所以，對於團隊來說，使用Node或Go來開發Web應用程式和服務可能並不是最好的選擇。

希望以上這些內容能夠協助你更清楚地瞭解底層發生的事情，並為你提供一些關於如何處理應用程式伸縮性的建議。

SDCC 2017之資料庫線上峰會即將強勢來襲，秉承乾貨實料（案例）的內容原則，邀請了來自阿里巴巴、騰訊、微博、網易等多家企業的資料庫專家及高校研究學者，圍繞Oracle、MySQL、PostgreSQL、Redis等熱點資料庫技術展開，從核心技術的深挖到高可用實踐的剖析，打造精華壓縮式分享，舉一反三，思辨互搏，報名及更多詳情可點擊此處查看。