SRPC性能测试问题 about srpc

[Barenboim]

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

[Barenboim]

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

[vinnie6seu]

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

[vinnie6seu]

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

[vinnie6seu]

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

[vinnie6seu]

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

[Barenboim]

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

[Barenboim]

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

[vinnie6seu]

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

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]

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

[vinnie6seu]

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]

发送的数据大小是一样的吗？

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2024年4月10日(周三) 晚上11:40 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [sogou/srpc] SRPC性能测试问题 (Issue #376) 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 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[Barenboim]

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

[vinnie6seu]

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

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

[ouclbc]

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

[Barenboim]

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

#377

[Barenboim]

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

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

[vinnie6seu]

1、执行BRPC案例./benchmark_client 10.200.63.56 8003 1024 32，客户端1024个并发下CPU消耗能到70%。
（1）客户端

（2）服务端

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

[holmes1412]

你好，我也试了下你的例子，你的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]

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

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]

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

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

[Barenboim]

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

[vinnie6seu]

按照各位老师提到的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

• 客户端
  
• 服务端
  

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

• 客户端
  
• 服务端
  

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

• 客户端
  
• 服务端
  

[Barenboim]

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

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

workflow和srpc不支持pipeline模式。

[vinnie6seu]

感谢各位专家的支持。

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

[Barenboim]

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