再次驗證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庫是否實現高效讀寫就對應用的效能有很大影響，抑或編碼過程中劣質的演算法或者邏輯可能會帶來效能巨大損耗，則會完全抵消語言本身在效能最佳化上帶來的提升，又比如從程式設計上合理使用緩衝，可以讓應用的某些操作效能提高一個數量級等等。。