以前簡單測過go的性能，高并發(fā)場景下確實比node會好一些，一直想找個時間系統(tǒng)性地測一下，手頭正好有一臺前段時間買的游戲主機，裝了ubuntu就開測了
準備工作
- 測試機和試壓機系統(tǒng)都是ubuntu 18.04.1
- 首先安裝node和go，版本分別如下：
- node 10.13.0
- go 1.11
- 測試機和試壓機修改fd的限制? ulimit -n 100000 ?，否則fd很快就用完了。
- 如果是試壓機是單機，并且QPS非常高的時候，也許你會經(jīng)常見到試壓機有N多的連接都是?TIME_WAIT?狀態(tài)，具體原因可以在網(wǎng)上搜一下，執(zhí)行以下命令即可：
$ sysctl -w net.ipv4.tcp_tw_reuse=1
$ sysctl -w net.ipv4.tcp_tw_recycle=```
</pre>
1. 測試工具我用的是siege，版本是?3.0.8?。
2. 測試的js代碼和go代碼分別如下：
Node（官網(wǎng)的cluster示例代碼）
```const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
// Fork workers.
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`worker ${worker.process.pid} died`);
});} else {
// Workers can share any TCP connection
// In this case it is an HTTP server
http.createServer((req, res) => {
res.end('hello world
');
}).listen(8000);
console.log(`Worker ${process.pid} started`);}
</pre>
**Go**
package main
import(
"net/http"
"fmt"
)
func hello(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "hello world")
}
func main() {
http.HandleFunc("/", hello);
err := http.ListenAndServe(":8000", nil);
if err != nil {
}
}
開始測試
首先開始并發(fā)量的測試，然而。。。游戲主機的CPU是i7-8700K，性能太強，以至于拿了兩臺mac也沒能壓滿。。。
四處尋找一番，找到了好幾年前花了千把塊錢配的nas，上去一看是顆雙核的i3-4170，妥了，這下肯定沒問題
正式開始
跳過了小插曲，直接開測
I/O密集型場景
- Node - 多進程模型，可以看到因為所有請求都由master進程轉發(fā)，master進程成為了瓶頸，在CPU占用100%的情況下，worker進程僅僅只占了50%，因此整體CPU利用率只有70%。
- qps: 6700
- Go - 單進程多線程模型，系統(tǒng)剩余CPU差不多也有30%，查了一下原因是因為網(wǎng)卡已經(jīng)被打滿了，千兆網(wǎng)卡看了下已經(jīng)扎扎實實被打滿了。
- qps: 37000
千兆網(wǎng)卡已經(jīng)被打滿了
在helloworld場景下，如果我們有萬兆網(wǎng)卡，那么go的qps就是50000，go是node的7倍多，乍一看這個結果就非常有意思了，下面我們分析下原因：
- 首先node官方給的cluster的例子去跑壓測是有問題的，CPU物理核心雙核，超線程成4核，姑且我們就認為有4核。
- cluster的方案，先起主進程，然后再起跟CPU數(shù)量一樣的子進程，所以現(xiàn)在總共5個進程，4個核心，就會造成上下文頻繁切換，QPS異常低下
- 基于以上結論，我減少了一個worker進程的數(shù)量
- Node 多進程模型下，1個主進程，3個worker進程
- qps: 15000 (直接翻倍)
以上的結果證明我們的想法是對的，并且這個場景下CPU利用率幾乎達到了100%，不是很穩(wěn)定，暫且我們可以認為壓滿了，所以我們可以認為1master4worker場景下，就是因為進程上下文頻繁切換導致的qps低下
那么進一步想，如果把進程和CPU綁定，是不是可以進一步提高qps?
- Node 多進程模型，并且用?taskset?命令把進程和CPU綁定了
- qps: 17000 (比不綁定cpu性能提高了10%多)
結論 ：node在把CPU壓滿的情況下，最高qps為：17000，而go在cpu利用率剩余30%的情況，qps已經(jīng)達到了37000，如果網(wǎng)卡允許，那么go理論上可以達到50000左右的qps，是node的2.9倍左右。
CPU密集場景
為了模擬CPU密集場景，并保證兩邊場景一致，我在node和go中，分別添加了一段如下代碼，每次請求循環(huán)100W次，然后相加：
var b int
for a := 0; a < 1000000; a ++ {
b = b + a
}
</pre>
- Node 多進程模型：這里我的測試方式是開了4個worker，因為在CPU密集場景下，瓶頸往往在woker進程，并且將4個進程分別和4個核綁定，master進程就讓他隨風飄搖吧
- qps: 3000
- go：go不用做特殊處理，不用感知進程數(shù)量，不用綁定cpu，改了代碼直接走起
- qps: 6700，依然是node的兩倍多
結論
Node因為用了V8，從而繼承了單進程單線程的特性，單進程單線程好處是邏輯簡單，什么鎖，什么信號量，什么同步，都是浮云，老夫都是await一把梭。
而V8因為最初是使用在瀏覽器中，各種設置放在node上看起來就不是非常合理，比如最大使用內(nèi)存在64位下才1.4G，雖然使用buffer可以避開這個問題，但始終是有這種限制，而且單線程的設計（磁盤I/0是多線程實現(xiàn)），注定了在如今的多核場景下必定要開多個進程，而多個進程又會帶來進程間通信問題。
Go不是很熟，但是前段時間小玩過幾次，挺有意思的，一直聽聞Go性能好，今天簡單測了下果然不錯，但是包管理和錯誤處理方式實在是讓我有點不爽。
總的來說在單機單應用的場景下，Go的性能總體在Node兩倍左右，微服務場景下，Go也能起多進程，不過相比在機制上就沒那么大優(yōu)勢了。
Node
優(yōu)點
- 單進程單線程，邏輯清晰
- 多進程間環(huán)境隔離，單個進程down掉不會影響其他進程
- 開發(fā)語言受眾廣，上手易
缺點
- 多進程模型下，注定對于多核的利用會比較復雜，需要針對不同場景（cpu密集或者I/O密集）來設計程序
- 語言本身因為歷史遺留問題，存在較多的坑。
Go
優(yōu)點
- 單進程多線程，單個進程即可利用N核
- 語言較為成熟，在語言層面就可以規(guī)避掉一些問題。
- 單從結果上來看，性能確實比node好。
缺點
- 包管理方案并不成熟，相對于npm來說，簡直被按在地上摩擦
- if err != nil ….
- 多線程語言無法避開同步，鎖，信號量等概念，如果對于鎖等處理不當，會使性能大大降低，甚至死鎖等。
- 本身就一個進程，稍有不慎，進程down了就玩完了。
本次給大家推薦一個免費的學習群，里面概括移動應用網(wǎng)站開發(fā)，css，html，webpack，vue node angular以及面試資源等。
對web開發(fā)技術感興趣的同學，歡迎加入Q群：582735936，不管你是小白還是大牛我都歡迎，還有大牛整理的一套高效率學習路線和教程與您免費分享，同時每天更新視頻資料。
最后，祝大家早日學有所成，拿到滿意offer，快速升職加薪，走上人生巔峰。
簡書著作權歸作者所有，任何形式的轉載都請聯(lián)系作者獲得授權并注明出處。
