再次驗證golang與node.js的http模塊性能對比測試

以前看過性能對比測試的文章，是關於node.js和golang的http模塊，簡單的helloworld功能，原文在此：

http://www.cnblogs.com/QLeelulu/archive/2012/08/12/2635261.html#2447171

再此文章以後，node.js和golang都升級了，node.js如今已經到了0.10,而golang也到了1.1版本，所以忽然想在前人的基礎上再作一次性能測試。

具體代碼仍然沿用引用文章裏面的。

硬件：雙cpu，型號爲xeon  E5620 2.40GHz，爲4核cpu，由於支持超線程，因此係統顯示邏輯cpu數爲16個。

軟件環境：centos6.0 。 node.js版本爲0.8.15,沒有使用如今最新的0.10.13 . golang爲最新的1.1。二者從版本新舊上來看並不對等，不過最後我會把node.js版本升級來對比。

測試工具：apache ab，測試參數爲併發1000，完成總數爲200000次。

node.js在1.2.4,8,16進程下每秒完成請求數爲：

5980

11300

15495

20435

21029

而golang在設置對應的核心數支持下的數據以下：

11109

16477

21874

21598

20527

圖形顯示以下：

從圖中能夠看到，在1,2,4核心支持的狀況下，golang的指標都領先於node.js,並且領先幅度不小，在30%左右。可是到了8,16核的時候，golang就出現了性能沒有提高或者小幅降低的現象，而node.js仍然爲增勢並最終反超。這種狀況是很奇怪的，按理說，服務器雙cpu，每顆4核心，加起來8個物理核心，若是說從8核心到16核只是cpu的超線程模擬出來的，不是真正的物理核心，那麼從4核到8核，是真正的物理核心的增長，按理說性能應該繼續增加的。經過top命令觀察16個邏輯cpu的使用狀況，發現golang在8核心和16核心的時候，16個邏輯cpu始終有3到6個負載很低，也就是golang沒有徹底使用全部的cpu或者是負載比較不均衡。相比之下node.js在設置16個進程的時候，16個邏輯cpu都使用到了。看來golang自行調度cpu核心的算法仍是有問題，沒有作到很好的負載，而node.js的多進程羣集方案經過操做系統來平衡負載，效果更好。

不過node.js雖然在16個進程的時候全部的邏輯cpu都利用起來了，可是消耗基本在25%-45%之間，而golang在設置16個核心支持的時候，邏輯cpu負載最重也只有20%！平均只有15%左右。

回頭回顧下前面說的node.js沒用使用最新版原本對比的問題，我下載了最新的0.10.13版本，很奇怪的是，相比

0.8.15,每秒完成數反而出現了20%-30%的降低 ，這是什麼狀況，不知道其餘人可碰到過這種問題。

另外，簡單對tornado3 也作了測試，python的版本爲2.6.5，由於python尚未真正的多核或者多線程支持，更不用說2.X版本，因此只作了一個線程的測試，數據爲2200次/每秒 ，性能只有前二者的20%-30% .差距很大，

並且當併發數提高到2000的時候就出現了socket錯誤：apr_socket_recv: Connection reset by peer (104)

而node.js和golang在設置5000個併發下都很穩定。

固然，以上的測試並無涉及到操做系統參數的優化，測試代碼也只是很是簡單的helloworld，實際開發過程當中，有太多影響系統性能的因素，應用程序的代碼須要調用不一樣的類庫，類庫實現的優良與否以及使用的頻度可能會對性能有很大影響，好比假設咱們的應用須要大量的磁盤i/o，這時候i/o庫是否實現高效讀寫就對應用的性能有很大影響，抑或編碼過程當中劣質的算法或者邏輯可能會帶來性能巨大損耗，則會徹底抵消語言自己在性能優化上帶來的提高，又好比從程序設計上合理使用緩存，可讓應用的某些操做性能提升一個數量級等等。。