Miao Ge
Miao Ge
> 例如用 #15 的例子，接收数据非常缓慢，耗时很长 上面的问题在我本地没跑出来，从上面的日志分析可能是带宽满了或者你局域网路由器达到极限了，局域网达到了50%的丢包率， 可以试试再本地跑几个虚拟机试试
> 1、我的是pc机，本机运行，用的无线网卡。 > 2、数据包要大，200000字节。 > > 我的猜测是数据包太大，拆分成了很多分片，每个分片都需要ack来回，造成了时间延长。 我这边用你的例子在本地跑了两个进程，连接的127.0.0.1，看带宽峰值在38MB，来回rtt打印的在10ms以内,所以我感觉可能是网卡问题或者路由器问题，快手那边用这个库做过类似的测试瓶颈也出现在了公司内部路由器。
> 测算下来，耗时在fec编，解码，平均耗时1毫秒，累计起来，延迟增加。 啥配置的cpu？怎么这么耗时，fec的编码可以独立出去搞个线程 ，解码现在还不好搞出去单独搞个线程
> i7-7700 3.6GHz > > 内存16g > > 测试10000个字节以下性能很好。 > > 100000个字节，就不行了。 > > > > 打印的时间代码 ReedSolomon： > > > > long start = System.currentTimeMillis(); > > // Do...
> windows10 > jdk1.8 有完整的测试代码吗？
系统：windows10 cpu: i7-3770 16G内存跑这个程序分析瓶颈在网络io，带宽跑到了600Mb  线程分析  kcp所有业务(fec编码解码，kcp组包合包等)占用了60%还没到瓶颈 因为windows下面是select模型性能会差一些 ，如果是linux或者mac下面会好很多
> cpu为何如此之高，如果开2个连接，直接占用到90%了。这点无法使用，能否优化？ 单个连接只会有2个线程处理，一个处理网络收发，一个处理kcp业务和fec编解码，最多占用两核，2个连接最多占用4核，你那边i7-7700是8线程的应该最多占用50%，得分析一下别的什么业务占用了cpu，比如windows下360会洗流量占用cpu > 我的无线网卡是300m的，同样条件下，tcp的情况要好很多，kcp的优势就没体现出来。 tcp有控流，kcp没有控流，如果流量打满了tcp确实会好很多 > fec算法部分是否考虑用c++,java调用dll方式呢？ java版本的fec确实跟c++和go版本有点差距，用dll的话需要点时间，这个版本的所有内存都是堆外的不受jvm的gc管制，得把堆外内存拷贝到堆内再传到c++层去处理这样子gc会加大具体性能不好评估。
试试1.4版本，fec会好一点
优化后的fec单核每秒大概400MB 加密+解密，可以满足需求了，有时间再进一步优化成c艹版本
650Mb的网卡跑满也就81.25MB，上面那个例子轻松跑满网卡，有延迟是正常的，瓶颈还是在这个无线网卡