socket 优化传输效率！！高手进

一个服务单 一个客户端

1.将服务器，和客户端都在本机上进行传输 很快
本机很快，1s可发几万次

2.将服务器放到 局域网内另一台 linux 机器，客户端放到windows 上进行发送的时候就很慢
  将服务器放到 局域网内另一台 windows 机器，客户端放到windows 进行发送，发送效率一样慢



客户端:
while（true){

一次发送的数据为 （8+15）=23字节，write（23字节）；
等服务端得响应 read（16字节）；

}
服务端：
while（true）{
接受，
然后返回 响应 12+4 = 16的字节

}

客户端发送23字节，循环发送1000次，用时 60s。

将socket TcpNodelay设置为true后效率有所提升
发送23字节，循环发送1000次，用时 3s。
settcpnodelay（true）

我定位影响效率的原因是 in.read()阻塞导致的.
settcpnodelay（flase）即默认情况下
每次read()耗时 202ms左右，write（） 0ms
settcpnodelay（true）即禁用negal算法，
每次read()耗时 1ms 左右，write（） 1-3ms左右
偶尔出现一次40ms的情况

请教各位大侠,该如何优化，网络传输，read阻塞的情况啊

是JVM虚拟机的对socket的网络发送，有限制？？

小弟先在此谢过！！



最新测试结果..

settcpnodelay（flase）
情况下
在一次发送 1536字节 获取响应70字节 循环一1000。。只需1500ms左右
在发送<1500字节的时候  获取响应70字节 循环一1000。。竟然达到 41000ms左右



settcpnodelay（true）
情况下
在一次发送 1536字节 获取响应70字节 循环一1000。。只需1500ms左右
在发送<1500字节的时候  获取响应70字节 循环一1000。。只需800ms左右






附带测试的小程序..
jar包中，包含源程序!
等待各位大侠优化~~


更多解决方案请进入code110技术导航站


方案优化1. 小数据包请将setNodelay(true);能够明显提升速度,此为TCP不延迟发送

评论

25 楼 ray_linn 2011-04-25  

本机就根本不走网卡，当然快。

24 楼 20921556 2011-04-25  

kimmking 写道

dennis_zane 写道

首先，你传输的都是十几个字节，所以一定要禁用nagle算法，也就是tcpNoDelay设置为true，提高响应速度。

其次，你的读写应该是批量的吧，发送接受都是搞一个byte数组缓冲区

其实感觉最大的问题不是nagle，也不是batch或buffer、async或sync，
这些都不会有那么大的差别。

目前 不到2k*1000次，1.5s的速度还是慢，
吞吐量不到2M/s

如果网络问题排除，则测试机器可能有问题，换一个机器+新装的系统试试。

用飞鸽传递..能达到 11-12MB/S

这样是否能排除机器的可能呢??

23 楼 20921556 2011-04-25  

kimmking 写道

dennis_zane 写道

首先，你传输的都是十几个字节，所以一定要禁用nagle算法，也就是tcpNoDelay设置为true，提高响应速度。

其次，你的读写应该是批量的吧，发送接受都是搞一个byte数组缓冲区

其实感觉最大的问题不是nagle，也不是batch或buffer、async或sync，
这些都不会有那么大的差别。

目前 不到2k*1000次，1.5s的速度还是慢，
吞吐量不到2M/s

如果网络问题排除，则测试机器可能有问题，换一个机器+新装的系统试试。

测试机器应该没有问题,
其它部门用C写的
转发这种频繁接收发送小数据包的时候,性能没有这么低呢！！

22 楼 20921556 2011-04-25  

dennis_zane 写道

kimmking 写道

dennis_zane 写道

首先，你传输的都是十几个字节，所以一定要禁用nagle算法，也就是tcpNoDelay设置为true，提高响应速度。

其次，你的读写应该是批量的吧，发送接受都是搞一个byte数组缓冲区

其实感觉最大的问题不是nagle，也不是batch或buffer、async或sync，
这些都不会有那么大的差别。

目前 不到2k*1000次，1.5s的速度还是慢，
吞吐量不到2M/s

如果网络问题排除，则测试机器可能有问题，换一个机器+新装的系统试试。

大量发这种小数据包，nagel算法的对响应的影响是非常大的，楼主自己测试的结果就可以看出来。

是的,,小数据包的情况下 竟用nagel算法，能明显看到效果!

没有禁用nagel
在字节数小于 1536的情况下 耗时竟然达到 41000ms左右

21 楼 dennis_zane 2011-04-25  

kimmking 写道

dennis_zane 写道

首先，你传输的都是十几个字节，所以一定要禁用nagle算法，也就是tcpNoDelay设置为true，提高响应速度。

其次，你的读写应该是批量的吧，发送接受都是搞一个byte数组缓冲区

其实感觉最大的问题不是nagle，也不是batch或buffer、async或sync，
这些都不会有那么大的差别。

目前 不到2k*1000次，1.5s的速度还是慢，
吞吐量不到2M/s

如果网络问题排除，则测试机器可能有问题，换一个机器+新装的系统试试。

大量发这种小数据包，nagel算法的对响应的影响是非常大的，楼主自己测试的结果就可以看出来。

20 楼 kimmking 2011-04-25  

dennis_zane 写道

首先，你传输的都是十几个字节，所以一定要禁用nagle算法，也就是tcpNoDelay设置为true，提高响应速度。

其次，你的读写应该是批量的吧，发送接受都是搞一个byte数组缓冲区

其实感觉最大的问题不是nagle，也不是batch或buffer、async或sync，
这些都不会有那么大的差别。

目前 不到2k*1000次，1.5s的速度还是慢，
吞吐量不到2M/s

如果网络问题排除，则测试机器可能有问题，换一个机器+新装的系统试试。

19 楼 fk! 2011-04-25  

楼主是服务器端用了多线程后，响应还这么慢？？

18 楼 dennis_zane 2011-04-25  

首先，你传输的都是十几个字节，所以一定要禁用nagle算法，也就是tcpNoDelay设置为true，提高响应速度。

其次，你的读写应该是批量的吧，发送接受都是搞一个byte数组缓冲区

17 楼 antjava 2011-04-25  

用 mina 吧 ，效率不错。

16 楼 Rager 2011-04-25  

坐等解决方法

15 楼 lyy3323 2011-04-25  

1. 参数优化，参考socketAPI。
2. 网络问题，read方法 并没有其他多余逻辑操作，

14 楼 20921556 2011-04-25  

几乎都是在 read()的阻塞造成的!
各位大侠,如何在优化这个read阻塞问题？？？

13 楼 20921556 2011-04-25  

jnduan 写道

你的jk配置了多少链接数啊？不会都堵在那里了吧？

连接数高了的情况下,应该从那几个方面进行优化呢？？

12 楼 20921556 2011-04-25  

jnduan 写道

你的jk配置了多少链接数啊？不会都堵在那里了吧？

连接数多的情况下,确实更慢！！

贴出来的情况,是只有1个客户端连接在发送数据的！

11 楼 jnduan 2011-04-25  

你的jk配置了多少链接数啊？不会都堵在那里了吧？

10 楼 20921556 2011-04-25  

tanjiazhang 写道

read是阻塞的，write是非阻塞的，比较它们的执行时间有意义吗。

并不是比较,
只是在2种不同情况下,他们执行的时间不一样..

问题在于,只有几个字节，write()需要1-3ms嘛？

9 楼 神之小丑 2011-04-25  

tanjiazhang 写道

有没有改成异步read试过？

貌似 java NIO 就是适合于这种短连接，I/O频繁的场景吧

8 楼 tanjiazhang 2011-04-25  

有没有改成异步read试过？

7 楼 tanjiazhang 2011-04-25  

read是阻塞的，write是非阻塞的，比较它们的执行时间有意义吗。

6 楼 lzj0470 2011-04-25  

设置发送缓存大点。接受缓存也设置大点。好象在默认的情况下。
如：socket.setBuff*