本文基本上這為兩篇文章的翻譯和整合 --
  Scalable networking And
  Why are event-driven server so great

傳統(tǒng)服務器模型如Apache為每一個請求生成一個子進程。當用戶連接到服務器的一個子進程就產(chǎn)生，并處理連接。每個連接獲得一個多帶帶的線程和子進程。當用戶請求數(shù)據(jù)返回時，子進程開始等待數(shù)據(jù)庫操作返回。如果此時另一個用戶也請求返回數(shù)據(jù)，這時就產(chǎn)生了阻塞。

這種模式在非常小的工作負荷是表現(xiàn)良好，當請求的數(shù)量變得太大是服務器會壓力過于巨大。 當Apache達到進程的最大數(shù)量，所有進程都變得緩慢。每個請求都有自己的線程，如果服務代碼使用PHP編寫時，每個進程所需要的內(nèi)存量是相當大的[1]。

事實上，基于OPPC的網(wǎng)絡并不如想象中的高效。首先新建進程的性能很大程度上依賴于操作系統(tǒng)對fork()的實現(xiàn)，然而不同操作系統(tǒng)的處理并非都理想。如圖為各操作系統(tǒng)fork()的延遲時間對比。

操作系統(tǒng)fork操作只是簡單的拷貝分頁映射。動態(tài)鏈接為共享庫和全局偏移表中的ELF（Executable and Linking Format）部分創(chuàng)建太多的分頁映射。雖然靜態(tài)的鏈接fork會是的性能大幅度提升，但是延時依然不樂觀。

圖 1 fork延時

Linux每10毫秒（Alpha是1毫秒，該值為已編譯常量）中斷一次在運行態(tài)的進程，查看是否要切換別的進程執(zhí)行。進程調(diào)度的任務就是決定下一個應該執(zhí)行的進程，而其難度就在于如何公平的分配CPU資源。一個好的調(diào)度算法應該給每一個進程都分享公平的CPU資源，而且不應該出現(xiàn)饑餓進程。

Unix系統(tǒng)采用多級反饋隊列調(diào)度算法。使用多個不同優(yōu)先級的就緒隊列，使用Heap保持隊列按優(yōu)先級順序排序。Linux 2.6版本提供了一個復雜度O(1)的調(diào)度算法，將進程調(diào)度延時降至最小。但是進程調(diào)度的頻率是100Hz，意味著10毫秒會中止一個進程而判斷是否需要切換到另一個進程。如果切換過多，會讓CPU忙于切換，導致降低吞吐量。

　　創(chuàng)建多進程會帶來另外一個問題：內(nèi)存消耗。

每一個創(chuàng)建的進程都會占用內(nèi)存，在Linux 2.6中的測試結(jié)果，400個左右的連接后fork()的性能要超過pthread_create()的性能。IBM對Linux做過優(yōu)化后，一個進程可以處理10萬個連接。fork（）在每一個連接時都fork()一次成本太高，多線程在于需要考慮線程安全(thread-safe)與死鎖(deadlock)，以及內(nèi)存泄露問題這些問題。 　　

該模型具有可靠性問題。一個配置不當?shù)姆掌?，很容易遭受拒絕服務攻擊（DoS）。當大量并發(fā)請求的服務器資源時，負載均衡配置不當時服務器會很快耗盡源而奔潰。

在這個模型中，應用程序執(zhí)行一個系統(tǒng)調(diào)用，這會導致應用程序阻塞。這意味著應用程序會一直阻塞，直到系統(tǒng)調(diào)用完成為止（數(shù)據(jù)傳輸完成或發(fā)生錯誤）。調(diào)用應用程序處于一種不再占用CPU，而只是簡單等待響應的狀態(tài)，但是該進程依然占用著資源。當大量并發(fā)I/O請求到達時，則會產(chǎn)生I/O阻塞，造成服務器瓶頸。

通過上訴分析與實驗說明，事實上，操作系統(tǒng)并不是設(shè)計來處理服務器工作負載。傳統(tǒng)的線程模型是基于運行應用程序是的一些密集型操作的需要。 操作系統(tǒng)的設(shè)計是讓用戶執(zhí)行的多線程程序，使后臺文件寫入和UI操作同時進行，而并不是設(shè)計于處理大量并發(fā)請求連接。

Fork和多線程是相當費資源的操作，創(chuàng)建線程需要分配一個全新的內(nèi)存堆棧。此外，上下文切換也是一項開銷的，CPU調(diào)度模型是并不太適合一個傳統(tǒng)的Web服務器。

因此，OPPC模型面臨著多進程多線程的延遲已經(jīng)內(nèi)存消耗的問題。要用OPPC模型解決C10K問題顯得十分復雜。

為解決C10K問題，一些新的服務器呈現(xiàn)出來。下列是解決C10K問題的Web服務器：

nginx：一個基于事件驅(qū)動的處理請求架構(gòu)反向代理服務器。

Cherokee：Twitter使用的開源Web服務器。

Tornado：一個Python語言實現(xiàn)的非阻塞式Web服務器框架。Facebook的FriendFeed模塊使用此框架完成。

Node.js：異步非阻塞Web服務器，運行于Google V8 JavaScript引擎。

顯然以上解決C10K問題的服務器都有著共同特點：事件驅(qū)動，異步非阻塞技術(shù)。

由于網(wǎng)絡負載工作包括大量的等待。比如 Apache服務器，產(chǎn)生大量的子進程，需要消耗大量內(nèi)存。但大多數(shù)子進程占用大量內(nèi)存資源卻只是在等待一個阻塞任務結(jié)束。由于這一特點，新模型拋棄了對每個請求生成子進程的想法。所有的請求和事物操作只使用一個多帶帶的線程管理，此線程被稱之為事件循環(huán)。事件循環(huán)將異步的管理所有用戶連接與文件存儲或數(shù)據(jù)庫服務器。當請求到達時，使用poll或者select喚醒操作系統(tǒng)對其請求做相應處理。解決了很多問題。這樣以來處理的并發(fā)請求不再是緊緊圍繞在阻塞資源。當然，這樣也有一定的開銷，如保持一個始終打開的TCP連接的列表，但內(nèi)存并不會由于大量并發(fā)請求而急速上升，因為這個列表只占內(nèi)存堆上很小的一部分。Node.js和Nginx的都用這種方法來構(gòu)建應用程序的規(guī)模超級大的連接數(shù)。一切操作都由一個事件循環(huán)管理，并很好地處理多個連接[4]（圖3）。

目前最為流行的事件驅(qū)動的異步非阻塞式I/O的Web服務器Node.js，稱其會在內(nèi)存占用上更為高效，而且由于不是傳統(tǒng)OPPC模式，也不用擔心死鎖。Node.js沒有函數(shù)直接執(zhí)行I/O操作[5]，因此也不會產(chǎn)生阻塞[6]。

圖 3 事件驅(qū)動模型

圖 4 傳統(tǒng)OPPC模型

本文對目前應用最廣的傳統(tǒng)模型的Apache+PHP服務器，與兩個流行事件驅(qū)動模型服務器Node.js，tornado，進行了壓力測試。使用Apache bench對三個服務器分別進行每次1000個并發(fā)請求，總共100000次請求測試。分別監(jiān)測和記錄了三個服務器的內(nèi)存與CPU占用情況。

實驗環(huán)境為Ubuntu 11.10，Intel Celeron 1.86GHzCPU,內(nèi)存1G(oh no,教研室的古董機子)。服務器分別為Apache2+PHP5.5,Node.js0.8.6和Tornado2.4.1。

{% include_code Nodejs nodeTest.sh %}

{% include_code Tornado tornadoTest.sh %}

{% include_code PHP phpTest.sh %}

圖4 內(nèi)存占用

圖 5 CPU占用

在這個1000并發(fā)請求的壓力測試中可以看到，基于事件驅(qū)動的Node.js與Tornado都比傳統(tǒng)OPPC模型的Apache服務器要快。當然Node.js的性能也離不開其運行于Google V8引擎上的原因。兩個事件驅(qū)動模型服務器平均每秒處理的請求數(shù)為Apache服務器的一倍，而內(nèi)存降低了一半。圖2顯示事件驅(qū)動模型服務器會占用更高的CPU，這說明這種模型雖然是單線程運行，但是能更高效的利用CPU處理更多的并發(fā)請求。

存在的不足

事件循環(huán)并不能解決一切問題[2]。特別是在Node.js的有一些缺陷。Node.js的最明顯的遺漏是多線程的實現(xiàn)。事件驅(qū)動技術(shù)似乎應該都是多線程進行的，如大多數(shù)事件驅(qū)動GUI框架。理論上來說，事件之間應該是相互獨立的關(guān)系，因此并行化應該并不難實現(xiàn)。

雖然理論上是這樣，但一些技術(shù)上的原因使得Node.js難以實現(xiàn)多線程。Node.js運行與Google的V8 Javascript引擎上[12]。V8引擎是一個高性能的JavaScript引擎，但它并沒有設(shè)計為多線程。因為它原本為Google Chrome瀏覽器Javascript引擎，瀏覽器中Javascropt在一個單線程上運行。因此添加多線程，將是非常艱難的，底層架構(gòu)并非為服務器而設(shè)計。

未來

隨著nginx這樣的反向代理服務器的發(fā)展，可以讓獨立運行的實例之間的負載均衡，Node.js的作者提出對解決多線程缺陷的最好的辦法是使用fork子進程，利用負載均衡來達到服務器并發(fā)任務處理。 這種解決方案似乎像是要掩蓋其實現(xiàn)上的缺陷。但事件驅(qū)動模型倡導一個邏輯服務器應該應該能在單核CPU下表現(xiàn)得最優(yōu)，以及占用更少的內(nèi)存。與此相反，Apache的最初目的是以一切可利用的資源為代價充分高效管理并發(fā)和線程。事件驅(qū)動模型服務器避開了這種繁瑣的設(shè)計而用最簡潔高效的方式實現(xiàn)了可擴展性良好的服務器。

單線程的也正符合云計算的平臺的計算單位。很明顯，一個單一的云實例，非常適合運行一個單一的Node.js的服務器，并使用負載均衡橫向擴展。

事件驅(qū)動模型的出現(xiàn)，是為了解決傳統(tǒng)服務器與網(wǎng)絡工作負載的需求的不匹配，實現(xiàn)高度可伸縮服務器，并降低內(nèi)存開銷。事情驅(qū)動模型更改了連接到服務器的方式。所有的連接都由事件循環(huán)管理，每個連接觸發(fā)一個在事件循環(huán)進程中運行的事件，而不是為每個連接生成一個新的 OS 線程，并為其分配一些配套內(nèi)存。因此不用擔心出現(xiàn)死鎖，而且不會直接調(diào)用阻塞資源，而采用異步的方式來實現(xiàn)非阻塞式I/O。通過事件驅(qū)動模型是的在相同配置的服務器能接受更多的并發(fā)請求，實現(xiàn)可伸縮的服務器。

[1] Suzumura, T.; Trent, S.; Tatsubori, M.; Tozawa, A.; Onodera, T.; , "Performance Comparison of Web Service Engines in PHP, Java and C," Web Services, 2008. ICWS "08. IEEE International Conference on , vol., no., pp.385-392, 23-26 Sept. 2008

[2] Von Behren, Rob, Jeremy Condit, and Eric Brewer. "Why events are a bad idea (for high-concurrency servers)." Proceedings of the 9th conference on Hot Topics in Operating Systems. Vol. 9. 2003.

[3]Welsh, Matt. "The staged event-driven architecture for highly-concurrent server applications." University of California, Berkeley (2000).

[4] Griffin, L., Ryan, K., de Leastar, E., Botvich, D., "Scaling Instant Messaging communication services: A comparison of blocking and non-blocking techniques", Computers and Communications (ISCC), 2011 IEEE Symposium on, On page(s): 550 - 557

[5] Tilkov, Stefan, and Steve Vinoski. "Node. js: Using JavaScript to build high-performance network programs." Internet Computing, IEEE 14.6 (2010): 80-83.

[6] Deitcher, Avi. "Simplicity and performance: JavaScript on the server." Linux Journal 2011.204 (2011): 3.

[11] W. Stevens. TCP/IP Illustrated Volume 3. Addison-Wesley, Reading, MA, 1996. [12]: http://code.google.com/apis/v8/design.html accessed