Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRPC性能测试问题 #376

Open
vinnie6seu opened this issue Apr 10, 2024 · 25 comments
Open

SRPC性能测试问题 #376

vinnie6seu opened this issue Apr 10, 2024 · 25 comments

Comments

@vinnie6seu
Copy link

vinnie6seu commented Apr 10, 2024

1、测试机器:
(1)CPU 4-chip/1-core/4-processor Intel Xeon Processor (Skylake, IBRS)
(2)万兆带宽

2、测试案例:跨机单client→单server在不同并发的QPS
Client = 1
ClientThread = 64, 128, 256, 512, 1024
RequestSize = 32
Duration = 20s
Server = 1
ServerIOThread = 16
ServerHandlerThread = 16

3、测试代码:srpc-0.10.2/benchmark

4、测试QPS分别是:56140, 59491, 61938, 63486, 74785

5、疑问:客户端和服务端机器CPU繁忙度均在40%左右,网络带宽远没有吃满,加客户端并发QPS提升很不明显,和官方给的SRPC Benchmark结论差距很大,是因为测试机器的原因,还是代码有什么可以调整的地方。

@Barenboim
Copy link
Contributor

你好。我们的性能比首页上的数据要好,因为那是开源之前的数据了。你两台机器之间的ping值是多少呢?有没有其它的测试作对比?

@Barenboim
Copy link
Contributor

不过我看到你是一个单核心的虚机,7w多qps好像也不低了啊。或许你那边的CPU占用率统计不太准确?

@vinnie6seu

This comment was marked as duplicate.

3 similar comments
@vinnie6seu

This comment was marked as duplicate.

@vinnie6seu

This comment was marked as duplicate.

@vinnie6seu
Copy link
Author

1、使用nmon进行监控。
2、抓取的是客户端并发1024,发送32字节数据。
3、是线程切换带来的开销么,造成CPU繁忙度不高,但是性能压不上去。
客户端
服务端

@Barenboim
Copy link
Contributor

你这个CPU占用率是40%不是20%。不过是有点低。
我们这边用了一台8核心的机器,同机运行server和client,CPU可以运行到100%,qps在1024并发的情况下是17万。
你试一下把server和client运行在同一台机器是什么效果。

@Barenboim
Copy link
Contributor

你发一下我们测试程序的完整输出吧。

@vinnie6seu
Copy link
Author

谢谢老师,这么晚辛苦解答疑惑了。

1、2个环境之间ping
ping 10.200.63.56
PING 10.200.63.56 (10.200.63.56) 56(84) bytes of data.
64 bytes from 10.200.63.56: icmp_seq=1 ttl=64 time=0.564 ms
64 bytes from 10.200.63.56: icmp_seq=2 ttl=64 time=0.201 ms
64 bytes from 10.200.63.56: icmp_seq=3 ttl=64 time=0.200 ms
64 bytes from 10.200.63.56: icmp_seq=4 ttl=64 time=0.190 ms
64 bytes from 10.200.63.56: icmp_seq=5 ttl=64 time=0.201 ms
64 bytes from 10.200.63.56: icmp_seq=6 ttl=64 time=0.196 ms
64 bytes from 10.200.63.56: icmp_seq=7 ttl=64 time=0.209 ms

2、./client 10.200.63.56 8888 srpc pb 1024 32

query 1288657 times, 1287633 success, 0 error.
total 20.034 seconds
qps=64324
latency=15911us

3、./server 8888 srpc 1
TIMESTAMP(ms) = 1712761667441 QPS = 1
TIMESTAMP(ms) = 1712761668000 QPS = 33033
TIMESTAMP(ms) = 1712761669005 QPS = 64437
TIMESTAMP(ms) = 1712761670000 QPS = 65225
TIMESTAMP(ms) = 1712761671000 QPS = 64271
TIMESTAMP(ms) = 1712761672001 QPS = 64770
TIMESTAMP(ms) = 1712761673002 QPS = 64696
TIMESTAMP(ms) = 1712761674000 QPS = 65112
TIMESTAMP(ms) = 1712761675000 QPS = 65274
TIMESTAMP(ms) = 1712761676000 QPS = 64758
TIMESTAMP(ms) = 1712761677000 QPS = 64140
TIMESTAMP(ms) = 1712761678001 QPS = 63607
TIMESTAMP(ms) = 1712761679001 QPS = 62598
TIMESTAMP(ms) = 1712761680000 QPS = 64344
TIMESTAMP(ms) = 1712761681000 QPS = 63939
TIMESTAMP(ms) = 1712761682000 QPS = 65672
TIMESTAMP(ms) = 1712761683000 QPS = 65409
TIMESTAMP(ms) = 1712761684000 QPS = 64147
TIMESTAMP(ms) = 1712761685000 QPS = 63342
TIMESTAMP(ms) = 1712761686000 QPS = 64358
TIMESTAMP(ms) = 1712761687000 QPS = 65153
^C
Total query: 1258286 max QPS: 65672

@Barenboim
Copy link
Contributor

latency=15911us
ping值很小,但latency这么大。我觉得可能你实际上CPU已经跑满了,但是因为你是虚拟机的原因,看不出来。实际上你可能并没有被分配到完整的4核。你把你的并行度降一下,看看lantency是否会同步下降。或者,你可以拿其它的rpc框架在相同环境对比一下。

@vinnie6seu
Copy link
Author

1、降低并发度的测试结果
./client 10.200.63.56 8888 srpc pb 512 32

query 1232240 times, 1231728 success, 0 error.
total 20.024 seconds
qps=61538
latency=8316us

./client 10.200.63.56 8888 srpc pb 256 32

query 1223467 times, 1223212 success, 0 error.
total 20.013 seconds
qps=61134
latency=4186us

./client 10.200.63.56 8888 srpc pb 128 32

query 1152636 times, 1152508 success, 0 error.
total 20.006 seconds
qps=57615
latency=2220us

./client 10.200.63.56 8888 srpc pb 64 32

query 1241350 times, 1241286 success, 0 error.
total 20.003 seconds
qps=62058
latency=1030us

./client 10.200.63.56 8888 srpc pb 32 32

query 1146939 times, 1146907 success, 0 error.
total 20.002 seconds
qps=57341
latency=557us

./client 10.200.63.56 8888 srpc pb 16 32

query 872128 times, 872112 success, 0 error.
total 20.001 seconds
qps=43604
latency=366us

2、拿brpc-1.5.0/example/asynchronous_echo_c++,模仿srpc benchmark代码修改出来,测试结果如下
./benchmark_client 10.200.63.56 8003 128 32

query(总请求数)=2377344, success(成功应答数)=2377216, error(失败应答数)=0.
total(客户端延迟持续时间)=20.007 seconds
qps(客户端计算出的QPS)=118826
latency(总的延迟时间)=1075us

I0410 23:18:32.203219 29033 client.cpp:238] BenchmarkClient is going to quit

./benchmark_client 10.200.63.56 8003 64 32

query(总请求数)=1758057, success(成功应答数)=1757993, error(失败应答数)=0.
total(客户端延迟持续时间)=20.006 seconds
qps(客户端计算出的QPS)=87876
latency(总的延迟时间)=726us

I0410 23:19:08.298106 29124 client.cpp:238] BenchmarkClient is going to quit

./benchmark_client 10.200.63.56 8003 32 32

query(总请求数)=1246619, success(成功应答数)=1246587, error(失败应答数)=0.
total(客户端延迟持续时间)=20.006 seconds
qps(客户端计算出的QPS)=62312
latency(总的延迟时间)=512us

I0410 23:19:40.808943 29237 client.cpp:238] BenchmarkClient is going to quit

@Barenboim
Copy link
Contributor

Barenboim commented Apr 10, 2024 via email

@Barenboim
Copy link
Contributor

我们明天也重复一下你的实验,顺便对比一下最新代码的性能。

@vinnie6seu
Copy link
Author

vinnie6seu commented Apr 11, 2024

1、我使用的测试代码版本号是:workflow-v0.11.1、srpc-0.10.2、brpc-1.5.0。
2、附件是我拿brpc改出来与srpc相似的benchmark代码,可放入brpc-1.5.0/example/中编译。
benchmark_c++.tar.gz

辛苦老师们,看下是否是我的测试方法有问题。

@Barenboim
Copy link
Contributor

怎么在代码里面修改client和server为单线程?

#377

@Barenboim
Copy link
Contributor

@vinnie6seu 我们初步测试,跨机情况下srpc和brpc性能差不多,在我们的测试机上都是15w+ qps。我们这边一直没有复现你试出来的CPU跑不满的情况。

brpc默认使用的是单连接模式,所以看到的连接数非常少。我一会用连接池模式再试一下。

@vinnie6seu
Copy link
Author

1、执行BRPC案例./benchmark_client 10.200.63.56 8003 1024 32,客户端1024个并发下CPU消耗能到70%。
(1)客户端
客户端0411
(2)服务端
服务端0411

2、我把SRPC的client和server的poller线程和handler线程,数量都调整成了32个,客户端试了128、256、1024个并发,始终CPU消耗都是40%左右,有些奇怪像似哪里被限制住了。

@holmes1412
Copy link
Contributor

holmes1412 commented Apr 11, 2024

你好,我也试了下你的例子,你的brpc client用的是pipeline模式,和连接池模式场景不同,这是你测出brpc性能明显区别比较大的原因。应该把connection_type设置成pooled才是类似的压测,你可以改了之后试一下。

所以以下使用brpc pooled的模式,并且都用brpc协议,分别使用两个client对两个server进行压测(固定client比较可以去掉发送请求模式的差异)。分了两组大实验,每大组实验都是大小32,使用3种并发值发2种server。qps和latency正相关所以只记录qps。机器环境10核,client和server都部署到同一台机器上。

并发:64 | 128 | 1024

第一组实验

brpc client → brpc server
QPS :14.9w | 15w | 14.6w

brpc client → srpc server
QPS : 12.4w | 14w | 14.3w

第二组实验

srpc client → brpc server
QPS : 12.8w | 14.2w | 15.4w

srpc client → srpc server
QPS :13.3w | 15.1w | 17.2w

一些目前的结论:

  • 并发128已经可以把cpu基本跑满,并发64的时候可以看出srpc server占用的cpu比brpc server少一点;
  • 最高的性能由srpc client压srpc server得出;

一些目前还未能解释的:

  • brpc client 发给brpc server并发增加之后,吞吐没有上去,稳定都在15w的样子。简单review过暂时没发现写法有什么问题,可能是发送方式导致;
  • 你的srpc还是跑不满cpu,这个我还需要想一想为啥;

@vinnie6seu
Copy link
Author

非常感谢各位专家的辛苦支持。

1、我把benchmark_c++.tar.gz中connection_type设置成pooled,确实测下来brpc和srpc的性能差异不大了。因为没有研究过brpc的代码,所以模仿示例代码临时改了一个出来,connection_type没有用对,确实不够严谨。
2、测试案例确实应该按照老师说的,应该控制变量,我会在按照你说得方式重新再测试下。
3、SRPC跑不满CPU的问题,比较奇怪。从测试结果来看,应该是机器的资源用满了(大概率是CPU),才导致QPS上不去。但是nmon 监控确显示比较空闲。
PS:brpc client如果是pipeline模式,客户端机器CPU,能被监控到压的比较高。如果是pooled模式,CPU也有些吃不上去。还有把srpc的client、server中poller、handler线程数调小,性能会更好一些(机器配置是4-chip/1-core/4-processor)。

@Barenboim
Copy link
Contributor

我们这边猜测,你虚机的网卡pps是不是有限制,导致pooled模式下qps上不了。而brpc的单连接模式,可能需要的数据包少一些(相邻请求合并了),所以可以传输的请求量也大一些。

我们之前有做过实验,正常情况下brpc的单连接极限qps都是低于pooled的。

@Barenboim
Copy link
Contributor

从packetin, packetout, insize, outsize几个值看,应该就是卡在了pps限制。你本机通过127.0.0.1来测试,应该没这个问题。

@vinnie6seu
Copy link
Author

按照各位老师提到的pooled模式、网卡pps,简单测试了下。

1、跨机单srpc client→单srpc server在不同并发的QPS。
Client = 1
ClientThread = 1024
RequestSize = 32
Duration = 20s
Server = 1
ServerIOThread = 16
ServerHandlerThread = 16
(1)得到QPS为63269。
(2)使用sar -n DEV 1 100000,监控PPS

  • 客户端
    image
  • 服务端
    image

2、跨机单brpc client(pooled模式)→单brpc server在不同并发的QPS。
Client = 1
ClientThread = 512
RequestSize = 32
Duration = 20s
Server = 1
(1)得到QPS为63988。
(2)使用sar -n DEV 1 100000,监控PPS

  • 客户端
    image
  • 服务端
    image

3、跨机单brpc client(pipeline模式)→单brpc server在不同并发的QPS。
Client = 1
ClientThread = 512
RequestSize = 32
Duration = 20s
Server = 1
(1)得到QPS为195265。
(2)使用sar -n DEV 1 100000,监控PPS

  • 客户端
    image
  • 服务端
    image

@Barenboim
Copy link
Contributor

嗯嗯,很明显的pipeline模式pps小,所以快。我相信是卡在这里了。

一般正常应用不太会有这种问题,pipeline相当于很多请求一次发送了。

workflow和srpc不支持pipeline模式。

@vinnie6seu
Copy link
Author

感谢各位专家的支持。

1、咨询了系统运维,目前我用的虚机用的是virtio技术的虚拟网卡,pps就不太行。
2、搞了2台物理机,计划测下物理机部署的性能。再申请容器(ipvs技术),计划测试下容器下的性能。

@Barenboim
Copy link
Contributor

你们可以根据实际业务模型测一下,一般正常业务也不需要那么大的pps。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants