以前简单测过go的性能,高并发场景下确实比node会好一些,一直想找个时间系统性地测一下,手头正好有一台前段时间买的游戏主机,装了ubuntu就开测了

准备工作

  1. 测试机和试压机系统都是ubuntu 18.04.1
  2. 首先安装node和go,版本分别如下:

    node 10.13.0

    go 1.11

  3. 测试机和试压机修改fd的限制​ulimit -n 100000​,否则fd很快就用完了。

  4. 如果是试压机是单机,并且QPS非常高的时候,也许你会经常见到试压机有N多的连接都是​TIME_WAIT​状态,具体原因可以在网上搜一下,执行以下命令即可:

    1
    2
    3
    $ sysctl -w net.ipv4.tcp_timestamps=1
    $ sysctl -w net.ipv4.tcp_tw_reuse=1
    $ sysctl -w net.ipv4.tcp_tw_recycle=1
  5. 测试工具我用的是siege,版本是​3.0.8​。

  6. 测试的js代码和go代码分别如下:

Node(官网的cluster示例代码)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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\n');
}).listen(8000);

console.log(`Worker ${process.pid} started`);}

Go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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


  • Go - 单进程多线程模型,系统剩余CPU差不多也有30%,查了一下原因是因为网卡已经被打满了,千兆网卡看了下已经扎扎实实被打满了。
  • qps: 37000

千兆网卡已经被打满了


在helloworld场景下,如果我们有万兆网卡,那么go的qps就是50000,go是node的7倍多,乍一看这个结果就非常有意思了,下面我们分析下原因:

  1. 首先node官方给的cluster的例子去跑压测是有问题的,CPU物理核心双核,超线程成4核,姑且我们就认为有4核。
  2. cluster的方案,先起主进程,然后再起跟CPU数量一样的子进程,所以现在总共5个进程,4个核心,就会造成上下文频繁切换,QPS异常低下
  3. 基于以上结论,我减少了一个worker进程的数量
  • Node 多进程模型下,1个主进程,3个worker进程
  • qps: 15000 (直接翻倍)


以上的结果证明我们的想法是对的,并且这个场景下CPU利用率几乎达到了100%,不是很稳定,暂且我们可以认为压满了,所以我们可以认为1master4worker场景下,就是因为进程上下文频繁切换导致的qps低下

那么进一步想,如果把进程和CPU绑定,是不是可以进一步提高qps?

  • Node 多进程模型,并且用​taskset​命令把进程和CPU绑定了
  • qps: 17000 (比不绑定cpu性能提高了10%多)


结论 :node在把CPU压满的情况下,最高qps为:17000,而go在cpu利用率剩余30%的情况,qps已经达到了37000,如果网卡允许,那么go理论上可以达到50000左右的qps,是node的2.9倍左右。

CPU密集场景

为了模拟CPU密集场景,并保证两边场景一致,我在node和go中,分别添加了一段如下代码,每次请求循环100W次,然后相加:

1
2
3
4
var b int
for a := 0; a < 1000000; a ++ {
b = b + a
}

  • Node 多进程模型:这里我的测试方式是开了4个worker,因为在CPU密集场景下,瓶颈往往在woker进程,并且将4个进程分别和4个核绑定,master进程就让他随风飘摇吧
  • qps: 3000


  • go:go不用做特殊处理,不用感知进程数量,不用绑定cpu,改了代码直接走起
  • qps: 6700,依然是node的两倍多

结论

Node因为用了V8,从而继承了单进程单线程的特性,单进程单线程好处是逻辑简单,什么锁,什么信号量,什么同步,都是浮云,老夫都是await一把梭。

而V8因为最初是使用在浏览器中,各种设置放在node上看起来就不是非常合理,比如最大使用内存在64位下才1.4G,虽然使用buffer可以避开这个问题,但始终是有这种限制,而且单线程的设计(磁盘I/0是多线程实现),注定了在如今的多核场景下必定要开多个进程,而多个进程又会带来进程间通信问题。

Go不是很熟,但是前段时间小玩过几次,挺有意思的,一直听闻Go性能好,今天简单测了下果然不错,但是包管理和错误处理方式实在是让我有点不爽。

总的来说在单机单应用的场景下,Go的性能总体在Node两倍左右,微服务场景下,Go也能起多进程,不过相比在机制上就没那么大优势了。

Node

优点

  1. 单进程单线程,逻辑清晰
  2. 多进程间环境隔离,单个进程down掉不会影响其他进程
  3. 开发语言受众广,上手易

缺点

  1. 多进程模型下,注定对于多核的利用会比较复杂,需要针对不同场景(cpu密集或者I/O密集)来设计程序
  2. 语言本身因为历史遗留问题,存在较多的坑。

Go

优点

  1. 单进程多线程,单个进程即可利用N核
  2. 语言较为成熟,在语言层面就可以规避掉一些问题。
  3. 单从结果上来看,性能确实比node好。

缺点

  1. 包管理方案并不成熟,相对于npm来说,简直被按在地上摩擦
  2. if err != nil ….
  3. 多线程语言无法避开同步,锁,信号量等概念,如果对于锁等处理不当,会使性能大大降低,甚至死锁等。
  4. 本身就一个进程,稍有不慎,进程down了就玩完了。
Go
Node, Go