multi--multi 模式下性能下降过多

[sols000]

msg_que 示例工程：

1. msg_que_t 改为 multi - multi - unicast
2. 打开一个 s 端 打开一个 r 端 （速度正常）
3. 再打开一个 r 端 ，速度下降得非常多

对比：
打开多个 s 端，1个r端，速度正常

[sols000]

在 Single - multi - broadcast 模式下 也是存在问题。（使用msg_que 工程测试）

[mutouyun]

你好，请问测试环境是windows还是linux，编译器、版本及编译参数是什么？

[sols000]

你好，请问测试环境是windows还是linux，编译器、版本及编译参数是什么？

系统：Windows
platform: Debug x64
编译器：vs2019
编译参数： 默认（由cmake自动生成）
测试方式： 开两个 r 端， 一个s端。
异常表现：性能下降过多，从4000M/s 下降到约 80M/s，关掉一个 r 端后，速率上升到约 150M/s
分支：master

Debug_x64_multi_multi_unicast.zip

[mutouyun]

额，性能测试请尽量不要用 debug 模式吧

[sols000]

额，性能测试请尽量不要用 debug 模式吧

用Release 测试了一下，也是一样的问题。

[sols000]

@mutouyun 这个点有优化打算吗

[mutouyun]

3415 MB/s
305 MB/s
3835 MB/s
375 MB/s
337 MB/s
388 MB/s
473 MB/s
388 MB/s
390 MB/s
511 MB/s
443 MB/s
3867 MB/s
69 MB/s
3 MB/s
262 MB/s
123 MB/s
190 MB/s
352 MB/s
988 MB/s
1193 MB/s

我测了一下，发现 smb 模式在 windows 上，多 r 端性能抖动很厉害。
并不是性能一直很差，而是间歇性的。
初步怀疑是无锁队列在 windows 上存在争用的性能问题。

周末我有整时间了再仔细看看。

[sols000]

3415 MB/s
305 MB/s
3835 MB/s
375 MB/s
337 MB/s
388 MB/s
473 MB/s
388 MB/s
390 MB/s
511 MB/s
443 MB/s
3867 MB/s
69 MB/s
3 MB/s
262 MB/s
123 MB/s
190 MB/s
352 MB/s
988 MB/s
1193 MB/s

我测了一下，发现 smb 模式在 windows 上，多 r 端性能抖动很厉害。
并不是性能一直很差，而是间歇性的。
初步怀疑是无锁队列在 windows 上存在争用的性能问题。

周末我有整时间了再仔细看看。

辛苦了

[mutouyun]

知道原因了。问题不是无锁争用上，毕竟之前做过性能测试，不至于有这么夸张的性能损失。。

原因是大message cache的回收上。
较大的message会尽量使用cache发送，只会产生一次memcpy（原因是用户内存必须拷贝到共享内存里），而且不会拆包组包，一次性就发过去了。
但cache的回收算法有bug，在unicast模式下，多receivers不会回收cache，导致cache被耗光，不得不将大message拆包发送。
在broadcast模式下，则是消息的回收和cache不一致，导致性能抖动。

See: issue-45

[mutouyun]

还是有bug，本质上是（大体积）消息消费的资源回收问题。。

[sols000]

OK, 我后面持续关注一下，这个issue 我先关了，看你另外open了一个。

[mutouyun]

我新开的那个是另外的bug。
关于这个问题，我已经合了一次 master，你可以测试一下，看看有没有改善。

[sols000]

@mutouyun 真不错，改动后的 1_s -- n_r 效果很好，1对1 性能好像也提升了 一倍的样子。

[mutouyun]

对了，尽量不要用 unicast 传大于 data_length（默认 64 bytes）的数据，因为现在 unicast 模式的拼包存在bug
见：#46