Benchmark

测试环境

• CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 24 cores
• Memory: 16G
• OS: Linux Server-3 2.6.32-358.el6.x86_64, CentOS 6.4
• Go: 1.7

测试代码client是通过protobuf编解码和server通讯的。 请求发送给server, server解码、更新两个字段、编码再发送给client，所以整个测试会包含客户端的编解码和服务器端的编解码。 消息的内容大约为581 byte, 在传输的过程中会增加少许的头信息，所以完整的消息大小在600字节左右。

测试用的proto文件如下：

syntax="proto2";
packagemain;
optionoptimize_for=SPEED;
messageBenchmarkMessage {
requiredstringfield1=1;
optionalstringfield9=9;
optionalstringfield18=18;
optionalboolfield80=80 [default=false];
optionalboolfield81=81 [default=true];
requiredint32field2=2;
requiredint32field3=3;
optionalint32field280=280;
optionalint32field6=6 [default=0];
optionalint64field22=22;
optionalstringfield4=4;
repeatedfixed64field5=5;
optionalboolfield59=59 [default=false];
optionalstringfield7=7;
optionalint32field16=16;
optionalint32field130=130 [default=0];
optionalboolfield12=12 [default=true];
optionalboolfield17=17 [default=true];
optionalboolfield13=13 [default=true];
optionalboolfield14=14 [default=true];
optionalint32field104=104 [default=0];
optionalint32field100=100 [default=0];
optionalint32field101=101 [default=0];
optionalstringfield102=102;
optionalstringfield103=103;
optionalint32field29=29 [default=0];
optionalboolfield30=30 [default=false];
optionalint32field60=60 [default=-1];
optionalint32field271=271 [default=-1];
optionalint32field272=272 [default=-1];
optionalint32field150=150;
optionalint32field23=23 [default=0];
optionalboolfield24=24 [default=false];
optionalint32field25=25 [default=0];
optionalboolfield78=78;
optionalint32field67=67 [default=0];
optionalint32field68=68;
optionalint32field128=128 [default=0];
optionalstringfield129=129 [default="xxxxxxxxxxxxxxxxxxxxx"];
optionalint32field131=131 [default=0];
}

测试的并发client是 100, 1000,2000 and 5000。总请求数一百万。

测试结果

一个服务器和一个客户端，在同一台机器上

并发client	平均值(ms)	中位数(ms)	最大值(ms)	最小值(ms)	吞吐率(TPS)
100	0	0	17	0	164338
500	2	1	40	0	181126
1000	4	3	56	0	186219
2000	9	7	105	0	182815
5000	25	22	200	0	178858

可以看出平均值和中位数值相差不大，说明没有太多的离谱的延迟。

随着并发数的增大，服务器延迟也越长，这是正常的。

客户端在一台机器上，服务器在另外一台机器上

如果我们把客户端和服务器端的程序放在两台独立机器上，这两台机器的配置和上面的测试相同。测试结果如下：

并发client	平均值(ms)	中位数(ms)	最大值(ms)	最小值(ms)	吞吐率(TPS)
100	1	1	20	0	127975
500	5	1	4350	0	136407
1000	10	2	3233	0	155255
2000	17	2	9735	0	159438
5000	44	2	12788	0	161917

因为与实际的网络传输，所以吞吐量没有上面的使用loopback的结果好，但是吞吐量已经不错了，接近每秒10万个事务处理。

客户端在一台机器上，两个服务器在另外两台机器上

如果部署成集群的模式，一个客户端，两个服务器端，测试结果如下：

并发client	平均值(ms)	中位数(ms)	最大值(ms)	最小值(ms)	吞吐率(TPS)
100	0	0	41	0	128932
500	3	2	273	0	150285
1000	5	5	621	0	150152
2000	10	7	288	0	159974
5000	23	12	629	0	155279

以下的代码是测试rpcx使用的序列化框架的性能。

[root@localhost rpcx]# go test -bench . -test.benchmem
PASS
BenchmarkNetRPC_gob-16 100000 18742 ns/op 321 B/op 9 allocs/op
BenchmarkNetRPC_jsonrpc-16 100000 21360 ns/op 1170 B/op 31 allocs/op
BenchmarkNetRPC_msgp-16 100000 18617 ns/op 776 B/op 35 allocs/op
BenchmarkRPCX_gob-16 100000 18718 ns/op 320 B/op 9 allocs/op
BenchmarkRPCX_json-16 100000 21238 ns/op 1170 B/op 31 allocs/op
BenchmarkRPCX_msgp-16 100000 18635 ns/op 776 B/op 35 allocs/op
BenchmarkRPCX_gencodec-16 100000 18454 ns/op 4485 B/op 17 allocs/op
BenchmarkRPCX_protobuf-16 100000 17234 ns/op 733 B/op 13 allocs/op

和gRPC比较

gRPC 是Google开发的一个RPC框架，支持多种编程语言。

我对gRPC和rpcx进行了相同的测试，得到了相应的测试结果。结果显示rpcx的性能要远远好于gRPC。 gRPC的优势之一就是随着并发数的增大，吞吐率比较稳定，而rpcx随着并发数的增加性能有所下降，但总体吞吐率还是要高于gRPC的。

rpcx的测试结果如上，下面事gRPC的测试结果。

一个服务器和一个客户端，在同一台机器上

并发client	平均值(ms)	中位数(ms)	最大值(ms)	最小值(ms)	吞吐率(TPS)
100	0	0	20	0	55561
500	7	6	59	0	62593
1000	14	12	103	0	65329
2000	28	24	163	0	67033
5000	71	64	380	0	63803

客户端在一台机器上，服务器在另外一台机器上

并发client	平均值(ms)	中位数(ms)	最大值(ms)	最小值(ms)	吞吐率(TPS)
100	1	0	21	0	68250
500	5	1	3059	0	78486
1000	10	1	6274	0	79980
2000	19	1	9736	0	58129
5000	43	2	14224	0	44724

客户端在一台机器上，两个服务器在另外两台机器上

并发client	平均值(ms)	中位数(ms)	最大值(ms)	最小值(ms)	吞吐率(TPS)
100	1	0	19	0	88082
500	4	1	1461	0	90334
1000	9	1	6315	0	62305
2000	17	1	9736	0	44487
5000	38	1	25087	0	33198