Replies: 6 comments
-
TQUIC可集成到多进程或多线程框架中。 直播数据流,很多时间是没有数据的(帧与帧之间有gap),也就是说拥塞控制模型常常会进入app-limited状态,可以等同于长连接上的大量的小文件请求(多路复用,但流之间有间隔)。 |
Beta Was this translation helpful? Give feedback.
-
是想压测传输性能, quic-go 我是写一个server, 收到请求后 就模拟直播的流 定时给客户端发送假数据,单路流带宽保持在1Mb/s |
Beta Was this translation helpful? Give feedback.
-
根据我个人的理解,从传输角度看,直播一般关注的不是传输性能(吞吐),而是传输效果,包括但不限于:成功率、首帧耗时(或者秒开率)、卡顿率(含次数和时长)、延迟等; 毕竟直播是要实时的数据,并不是说下载速率越大,传输效果就越好,对吧? 传输性能/效果,和拥塞控制算法及相关参数的设置关系比较大,和实现的语言以及是否多线程关系都不大哈。同样的拥塞控制算法,比如BBR,只要算法实现准确,传输效果得靠各使用者根据自己的业务模型对算法进行相应的调整来达成,不是各开源QUIC库的默认配置(不同开源库中的相同拥塞控制算法初始参数不一样,实际应用时,都需要使用者根据自己需要来更新配置)就能适配所有场景哈。 最后: 我们后续会将部分业务场景,用各开源库的各个常见拥塞算法(设置相同的参数)测试效果(传输性能),放出来供大家参考,您这边可以关注下哈。 |
Beta Was this translation helpful? Give feedback.
-
我们比较关注机器成本, quic消耗CPU 本身就比较多, 想对比下不同的语言 在io发送性能的差距大不大 |
Beta Was this translation helpful? Give feedback.
-
根据您上面提到的信息,实际上您关注的是单机性能,而非传输性能(吞吐),那您可以直接参考我们对业界几个比较优秀的开源库的性能测试数据哈,链接:https://tquic.net/zh/docs/further_readings/benchmark/ quic-go这个库我们没有在上面链接中做对比,主要是这个早几年大家都已经有比较明确的结论了,您可以在网上搜索到很多参考数据哈。 另外提下,TQUIC是一个实现QUIC协议栈的库,socket相关读写是由集成的框架负责的哈。 |
Beta Was this translation helpful? Give feedback.
-
好的,我再看看,感谢 |
Beta Was this translation helpful? Give feedback.
-
你好,有多线程服务端的压测数据吗
想测试下 多线程情况下, server 持续发送数据1Mb/s 给客户端, 看看这种场景下的性能
背景是 评估直播场景下 这个库的性能怎么样
Beta Was this translation helpful? Give feedback.
All reactions