以前简单测过go的性能，高并发场景下确实比node会好一些，一直想找个时间系统性地测一下，手头正好有一台前段时间买的游戏主机，装了ubuntu就开测了
准备工作
- 测试机和试压机系统都是ubuntu 18.04.1
- 首先安装node和go，版本分别如下：
- node 10.13.0
- go 1.11
- 测试机和试压机修改fd的限制 ulimit -n 100000 ，否则fd很快就用完了。
- 如果是试压机是单机，并且QPS非常高的时候，也许你会经常见到试压机有N多的连接都是TIME_WAIT状态，具体原因可以在网上搜一下，执行以下命令即可：
$ 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（官网的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 {
}
}
开始测试
首先开始并发量的测试，然而。。。游戏主机的CPU是i7-8700K，性能太强，以至于拿了两台mac也没能压满。。。
四处寻找一番，找到了好几年前花了千把块钱配的nas，上去一看是颗双核的i3-4170，妥了，这下肯定没问题
正式开始
跳过了小插曲，直接开测
I/O密集型场景
- Node - 多进程模型，可以看到因为所有请求都由master进程转发，master进程成为了瓶颈，在CPU占用100%的情况下，worker进程仅仅只占了50%，因此整体CPU利用率只有70%。
- qps: 6700
记一次Node和Go的性能测试
- Go - 单进程多线程模型，系统剩余CPU差不多也有30%，查了一下原因是因为网卡已经被打满了，千兆网卡看了下已经扎扎实实被打满了。
- qps: 37000
记一次Node和Go的性能测试
千兆网卡已经被打满了
记一次Node和Go的性能测试
在helloworld场景下，如果我们有万兆网卡，那么go的qps就是50000，go是node的7倍多，乍一看这个结果就非常有意思了，下面我们分析下原因：
- 首先node官方给的cluster的例子去跑压测是有问题的，CPU物理核心双核，超线程成4核，姑且我们就认为有4核。
- cluster的方案，先起主进程，然后再起跟CPU数量一样的子进程，所以现在总共5个进程，4个核心，就会造成上下文频繁切换，QPS异常低下
- 基于以上结论，我减少了一个worker进程的数量
- Node 多进程模型下，1个主进程，3个worker进程
- qps: 15000 (直接翻倍)
记一次Node和Go的性能测试
以上的结果证明我们的想法是对的，并且这个场景下CPU利用率几乎达到了100%，不是很稳定，暂且我们可以认为压满了，所以我们可以认为1master4worker场景下，就是因为进程上下文频繁切换导致的qps低下
那么进一步想，如果把进程和CPU绑定，是不是可以进一步提高qps?
- Node 多进程模型，并且用taskset命令把进程和CPU绑定了
- qps: 17000 (比不绑定cpu性能提高了10%多)
记一次Node和Go的性能测试
结论 ：node在把CPU压满的情况下，最高qps为：17000，而go在cpu利用率剩余30%的情况，qps已经达到了37000，如果网卡允许，那么go理论上可以达到50000左右的qps，是node的2.9倍左右。
CPU密集场景
为了模拟CPU密集场景，并保证两边场景一致，我在node和go中，分别添加了一段如下代码，每次请求循环100W次，然后相加：
var b int
for a := 0; a < 1000000; a ++ {
b = b + a
}
</pre>
- Node 多进程模型：这里我的测试方式是开了4个worker，因为在CPU密集场景下，瓶颈往往在woker进程，并且将4个进程分别和4个核绑定，master进程就让他随风飘摇吧
- qps: 3000
记一次Node和Go的性能测试
- go：go不用做特殊处理，不用感知进程数量，不用绑定cpu，改了代码直接走起
- qps: 6700，依然是node的两倍多
记一次Node和Go的性能测试
结论
Node因为用了V8，从而继承了单进程单线程的特性，单进程单线程好处是逻辑简单，什么锁，什么信号量，什么同步，都是浮云，老夫都是await一把梭。
而V8因为最初是使用在浏览器中，各种设置放在node上看起来就不是非常合理，比如最大使用内存在64位下才1.4G，虽然使用buffer可以避开这个问题，但始终是有这种限制，而且单线程的设计（磁盘I/0是多线程实现），注定了在如今的多核场景下必定要开多个进程，而多个进程又会带来进程间通信问题。
Go不是很熟，但是前段时间小玩过几次，挺有意思的，一直听闻Go性能好，今天简单测了下果然不错，但是包管理和错误处理方式实在是让我有点不爽。
总的来说在单机单应用的场景下，Go的性能总体在Node两倍左右，微服务场景下，Go也能起多进程，不过相比在机制上就没那么大优势了。
Node
优点
- 单进程单线程，逻辑清晰
- 多进程间环境隔离，单个进程down掉不会影响其他进程
- 开发语言受众广，上手易
缺点
- 多进程模型下，注定对于多核的利用会比较复杂，需要针对不同场景（cpu密集或者I/O密集）来设计程序
- 语言本身因为历史遗留问题，存在较多的坑。
Go
优点
- 单进程多线程，单个进程即可利用N核
- 语言较为成熟，在语言层面就可以规避掉一些问题。
- 单从结果上来看，性能确实比node好。
缺点
- 包管理方案并不成熟，相对于npm来说，简直被按在地上摩擦
- if err != nil ….
- 多线程语言无法避开同步，锁，信号量等概念，如果对于锁等处理不当，会使性能大大降低，甚至死锁等。
- 本身就一个进程，稍有不慎，进程down了就玩完了。
本次给大家推荐一个免费的学习群，里面概括移动应用网站开发，css，html，webpack，vue node angular以及面试资源等。
对web开发技术感兴趣的同学，欢迎加入Q群：582735936，不管你是小白还是大牛我都欢迎，还有大牛整理的一套高效率学习路线和教程与您免费分享，同时每天更新视频资料。
最后，祝大家早日学有所成，拿到满意offer，快速升职加薪，走上人生巅峰。
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
网友评论