如何在不调高cc并发值的情况下测试吞吐率？

[jiawen94]

我正在测试一条TCP隧道的吞吐率性能。
看了相关的文章和配置模板，大致就是调高CC，调小keepalive（比如1ms）
目前遇到的情况是，CC并发值过高会增加DUT的CPU的负担，反而达不到预期的性能；CC如果调小，dperf无法将带宽压满。而keepalive似乎最小只能是1ms，不能更小了。
请问有什么方法，在不增加CC的情况下，测试吞吐率？

[jiawen94]

请问keepalive有办法继续调小吗？

[pengjianzhang]

暂时只能调到1ms，你当前CC多少，你需要keepalive多小？

[jiawen94]

我当前cc=80，keepalive=1ms，那台低性能的DUT的cpu已经接近满负荷了。（DUT的TCP隧道服务对established的连接非常敏感，连接一高就CPU满载）
我曾经把cc=870，keepalive=1ms，在高性能DUT上就没出现这种尴尬的问题。
keepalive我当然是希望越小越好，比如0.1ms。
如果keepalive不能继续改小，还有其他方法解决吗？

[pengjianzhang]

如果这个DUT性能不高，为什么不用iperf，ab，wrk等测试？
调到0.1ms 可以考虑在下个版本支持

[jiawen94]

主要需求是为了测试不同数据包大小的吞吐率（比如64 bytes，128 bytes，256 bytes..）。
其他工具也试过，但经过抓包分析，对数据包的大小控制很不准确。dperf对数据包的控制非常准确。
另外，要不让dperf支持0.01ms吧，我估计0.1ms对我的环境而言，还有点悬

[pengjianzhang]

你直接修改代码，测试一下吧
config_parse_keepalive_request_interval（）
{
cfg->keepalive_request_interval = val * rate / 100;
}

[jiawen94]

请问这种修改方式的含义，是不是keepalive依然配置成1ms，但dperf会按照1ms/100作为间隔执行？
因为我直接修改keepalive为0.01ms会出现配置文件的错误

[pengjianzhang]

请问这种修改方式的含义，是不是keepalive依然配置成1ms，但dperf会按照1ms/100作为间隔执行？

是，需要修改C代码，重新编译

因为我直接修改keepalive为0.01ms会出现配置文件的错误

是，配置文件还不支持这样设置，只能先硬编码，先测试一下

[pengjianzhang]

符合预期吗？

[jiawen94]

我刚才直接改成/1000,然后编译，在较低CC的情况下，吞吐率确实有小幅度提升，但是还没达到预期（测试大包，和iperf对比的）

[pengjianzhang]

/10试试， dperf的定时器精度只有0.1ms

[jiawen94]

/10也试了一下，有提升，但是提升不大。
iperf大包测试，进出吞吐率900/600 Mbps
dperf（未改源码）测试，进出吞吐率为230/230 Mbps，DUT CPU 65%左右
dperf（间隔改为/10之后编译）测试，进出吞吐率为310/310 Mbps，DUT CPU 80%左右

我期望用dperf能跑出750/750 Mbps的吞吐率（参考iperf结果）

服务端配置

mode    server
cpu     3
tx_burst    1024
protocol    tcp
duration        80s
packet_size     1428
keepalive   1ms

port    0000:08:00.0    172.30.10.10    172.30.10.1     68:ed:a4:0d:9f:33
client  172.30.10.1     1
server  172.30.10.10    1
listen  44011   1

socket_mem  0

客户端配置

mode    client
tx_burst    1024
launch_num  10
cpu 4
protocol    tcp #测试的是TCP隧道，所以用TCP协议
packet_size     1428

duration        80s

cps 120
cc  50
keepalive   1ms

port    0000:08:00.1    172.30.15.10    172.30.15.1     00:22:46:3f:65:a4

client  172.30.15.10    1
server  172.30.15.1     1
listen  44011   1

socket_mem  0 #服务端和客户端在同一台设备上

[jiawen94]

会不会还需要修改别的地方的代码？

[pengjianzhang]

1， tx_burst 注释掉
2， cc调大一点
3， 如果是物理机的话，增加CPU个数为2个，增加服务器IP为2个

[pengjianzhang]

请用这个分支测试一下， 设置keepalive 1ms，硬编码为0.01ms了
https://github.com/pengjianzhang/dperf/tree/tick

tx_burst 注释掉

[jiawen94]

用tick分支编译了，但是跑出来的结果和昨天手动修改/10的结果差不多。tx_burst 注释掉了。

[jiawen94]

绑定2个CPU也试了，没有多余的网口，rss 选择 auto。似乎CC一直在增加（DUT查看established的连接一直在增加）

[pengjianzhang]

并发连接数(cc)能调高吗

[pengjianzhang]

绑定2个CPU也试了，没有多余的网口，rss 选择 auto。似乎CC一直在增加（DUT查看established的连接一直在增加）

如果是物理机，不要设置rss，用fidr特性，需要server上配置的IP数等于启用的CPU数；否则不要用rss

[pengjianzhang]

修复了一个Bug，现在可以了。
https://github.com/pengjianzhang/dperf/tree/tick

[jiawen94]

用最新的代码进行编译，吞吐率依然没什么提升。
另外，是否可以这么理解，你修改代码后，在不修改CC和keepalive配置的情况下，发包的速度是原来的100倍？

[pengjianzhang]

是的，我用UDP测试，是可以的。
你这样设置：
protocol udp
keepalive 10ms
cc 1

我的配置：
mode client
protocol udp

tx_burst 4

#rss auto
payload_size 64

keepalive 1ms
#cc 3200
cc 1
#cc 3000
#cps 1000

cpu 0

[jiawen94]

我没法用udp，因为dut隧道只支持传输tcp包。
keepalive 10ms cc 1 修改后，性能反而比原先还要差很多很多

[pengjianzhang]

TCP是没有问题的

[pengjianzhang]

请重新拉取分支 https://github.com/pengjianzhang/dperf/tree/tick， 谢谢

TCP 的PPS更加精确，这是我测试单TCP连接测试 10K PPS

seconds 53 cpuUsage 1
pktRx 10,001 pktTx 10,000 bitsRx 9,920,992 bitsTx 9,840,000 dropTx 0
tcpRx 10,001 tcpTx 10,000 udpRx 0 udpTx 0
arpRx 0 arpTx 0 icmpRx 0 icmpTx 0
tosRx 0 otherRx 0 badRx 0
synRx 0 synTx 0 finRx 0 finTx 0 rstRx 0 rstTx 0
synRt 0 finRt 0 ackRt 0 pushRt 0
tcpDrop 0 udpDrop 0
skOpen 0 skClose 0 skCon 1 skErr 0
httpGet 10,000 http2XX 10,001 httpErr 0
ierrors 0 oerrors 0 imissed 0

[pengjianzhang]

麻烦反馈一下测试结果，谢谢~

[jiawen94]

稍等一下，我这两天在处理其他高优先级的任务。
如果有进展，我会及时更新上去

[jiawen94]

1.对于性能测试结果，询问了研发人员，iperf的测试结果应该不准（偏高太多），不能作为参考，dperf的测试结果看起来可能是准确的。
2.我在一条隧道上比较了1.2分支和最新tick分支的性能（1428 字节大包），性能有提升，但不也没有百倍提升。

cc	1.2分支	tick分支
4	双向28 Mbps	双向73 Mbps
16	双向102Mbps	双向215Mbps
32	双向190Mbps	双向357Mbps

配置：

mode    server
cpu     3
#tx_burst    1024
protocol    tcp
duration        60s
packet_size     1428
keepalive   1ms

port    0000:08:00.0    172.30.15.10    172.30.15.1     
client  172.30.15.1     1
server  172.30.15.10    1
listen  44012   1

socket_mem  0

mode    client
#tx_burst    1024
launch_num  10
cpu 4
protocol    tcp
packet_size     1428

duration        60s

cps 128
cc      32 #按情况修改
keepalive   1ms

port    0000:08:00.1    172.30.175.10   172.30.175.1    

client  172.30.175.10   1
server  172.30.175.1    1
listen  44012   1

socket_mem  0

[pengjianzhang]

谢谢 你们的测试和反馈

建议server 上keepalive设置为 1s，避免不必要的重传。
能不能提升100倍 与latency、网卡性能有关系；如果把client keepalive 10ms，提升10倍应该是可以的吧。

😄，问一下，研发给dperf加⭐️了吗~~~~~？

[jiawen94]

不好意思问他加没加⭐，因为那位研发是我老板😅

[pengjianzhang]

难道不想和作者互动一下吗，这个特性可是花了很多精力的，开玩笑的，😊，非常感谢你们的合作，让dperf又进步了一点点

你们能写一篇文章，介绍一下这次测试，对比一下dperf与iperf吗，我想有很多人好奇，dperf与iperf测试带宽有什么不一样，这将是非常有意义的文章。请把文章提交到项目里，挂到项目主页上

[jiawen94]

改成1s，确实差不多100倍提升。不过我觉得keepalive改小点，性能更好，也就不需要那么大的并发数。
以下是keepalive 1s的吞吐率结果

cc	1.2分支	tick分支
4	双向48 kbps	双向4.5 Mbps

等“研发”心情好了，我问问他😄

[jiawen94]

我抽空会分享 为什么测试小包时，dperf对比iperf更精准。
至于本次测试，目前没找到iperf结果偏高的原因，其中也可能涉及到DUT的配置，属于公司隐私，所以这一部分不方便分享出。

[pengjianzhang]

该功能已经合入主干，可以配置"keepalive 10us"，试一下吧~~