Readv 严重问题，拖累速度、造成闪退
e1732a364fed opened this issue · 2 comments
e1732a364fed commented
之前写readv代码时只是简单试试好不好使，从来没经过 流量巨大的 测速测试
这次测速揭露出巨大问题
tls+vless
开启readv
1771 3488
1694 3103
关闭readv
3835 3536
3475 3604
ws+tls+vless
开启readv
2906 2435
2777 2424
2782 2436
关闭readv
2823 2447
2918 2445
readv本应加速，结果现在确实减速状态；
而测试ws+vless，中间不加tls层时，服务端则是直接闪退了
2022/03/26 17:26:44 direct 127.0.0.1:49281 want to dial tcp+direct ://54.244.7.161:443
panic: runtime error: slice bounds out of range [:1500] with capacity 935
panic: runtime error: slice bounds out of range [:1500] with capacity 935
/v2ray_simple/utils.RecoverBuffers(...)
v2ray_simple/utils/buffers.go:116
/v2ray_simple/netLayer.put_readvMem(0x14000064d18?)
v2ray_simple/netLayer/readv.go:53 +0xf8
总之代码我还要改改！现在大家先用 -readv=false 参数 或者
[app]
noreadv = true
关闭readv功能
e1732a364fed commented
我在最新commit中已经修复了闪退问题。
关于拖慢速度问题，我经过测试调节，发现是readv单个buf 大小的问题
经过排查，果然是buf大小问题，数据如下：
ws+vless，单机内网 使用自建speedtest工具自己连自己测速
关闭readv
2925 2524
3028 2512
2911 2558
开readv，buf 1500，16个
2405 2479
2373 2468
2534 2489
开readv但不用 multiwriter
1698 1957
1717 2021
buf 为 4096的情况, 数量为16
2755 2435
buf 为 10240的情况
3001 2538
2865 2513
2942 2544
2962 2511
buf 为 4096，数量为 32
2763 2513
2730 2540
2868 2543
2803 2534
buf 为 4096，数量为 320
2690 2514
2919 2484
2781 2537
2776 2485
总之，我的想法就是，在本地内网测速这种超快的极限的情况下，使用readv因为buf太小，会导致反效果而减速
如果是远程测速，反效果应该会减弱，甚至有正效果。这个我之前的benchmark也揭示过
所以实际上真不好说readv是好还是坏，看你的网络情况
个人推测，因为远程测速总是会经过多个网关，所以readv应该是有正效果的。同时，我也会进一步测试 readv最优化的参数。
e1732a364fed commented
关于该减速问题的思考，可以阅读
https://github.com/e1732a364fed/v2ray_simple/wiki/关于readv
在该页面里，我对这种现象进行了具体的解释。