摘要：本文首先簡單介紹了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應用程序和服務可能并不是最好的選擇。

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

來自：http://www.iteye.com/news/32826