Java NIO框架Netty教程(十三)-并发访问测试(下)

在上节(《Java NIO框架Netty教程(十二)-并发访问测试(中)》)，我们从各个角度对Netty并发的场景进行了测试。这节，我们将重点关注上节最后提到的问题。在多线程并发访问的情况下，会出现

警告: EXCEPTION, please implement one.coder.netty.chapter.eight.ObjectClientHandler.exceptionCaught() for proper handling.

java.net.ConnectException: Connection refused: no further information

的错误警告。

 

之前 OneCoder层怀疑过是端口数不够的问题，所以还准备了一套修改操作系统端口数限制的配置。

a) windows – 

1、打开注册表：regedit

2、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters

3、新建 DWORD值，name：TcpTimedWaitDelay，value：0（十进制） –> 设置为0

4、新建 DWORD值，name：MaxUserPort，value：65534（十进制） –> 设置最大连接数65534

5、重启系统

 

b) linux –

1、查看有关的选项 /sbin/sysctl -a|grep net.ipv4.tcp_tw 

   net.ipv4.tcp_tw_reuse = 0 

   #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

   net.ipv4.tcp_tw_recycle = 0 

   #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭

2、修改 vi /etc/sysctl.conf

   net.ipv4.tcp_tw_reuse = 1 

   net.ipv4.tcp_tw_recycle = 1 

3、使内核参数生效sysctl -p

这套配置在测试Restlet框架并发的时候，起到了明显的效果。

 

然后，这次即使  OneCoder 修改配置，并发连接也没有明显的上升。  OneCoder 决定换个思路，启动多个进程对同一个服务进行持续访问，以证明之前的连接拒绝就是因为客户端多线程并发自身的问题(其实  OneCoder 一直非常怀疑是这个问题)还是服务端连接处理的问题。

 

修改了一下客户端发动消息的代码，使其在其线程内部，不停的给服务端发送信息。

?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

/**       * 发送Object       *       * @param channel       * @author lihzh       * @alia OneCoder           * @blog http://www.coderli.com       */      private void sendObject( final Channel channel) {          new Thread( new Runnable() {                @Override              public void run() {                  // TODO Auto-generated method stub                  for (;;) {                      Command command = new Command();                      command.setActionName( "Hello action." );                      channel.write(command);                      try {                          Thread.sleep( 1000 );                      } catch (InterruptedException e) {                          e.printStackTrace();                      }                  }              }          }).start();      }

启动多个客户端，效果如图：

 

果然，在单个进程数量控制合理的情况下，服务端可以处理所有请求，不会出现链接拒绝的情况。总连接数轻松达到4，5k。（  OneCoder 注：以前超过1000都容易出错。这里只是测试到以前完全没有办法支持的情形，并没有测试最大压力值。）

 

对于测试Netty服务端压力来说，这样的测试，  OneCoder 认为完全可以起到效果，有参考价值。因为即使单进程网络连接方面无上限，单进程能启动的线程数也是有限制的，效率也一定会受到影响。所以，对于并发测试来说，  OneCoder 认为可以采用上面的方式。

 

对于，单进程多线程的时，拒绝连接的问题。是在sun.nio.ch.SocketChannelImple 中的native方法checkConnect中抛出的。这应该是跟操作系统密切相关的。  OneCoder 没有在linux下进行测试，但是猜测在linux下，上面的设置参数是可以起到作用的，也就是会比windows下可以开启的并发线程数多。当然这只是猜测。

 

对于windows来说，揪净能开启多个线程的并发，这个数据在  OneCoder 的环境下也是非常不稳定的。最开始的时候是，起1000个线程，成功的350个线程左右。后来，  OneCoder 怀疑启动的程序过多，尤其是跟网络相关的程序会影响测试结果，关闭了很多程序。结果，多次1000线程都成功连接。

 

OneCoder仔细排查了一下，猛然发现  OneCoder 使用了Proxifier这个代理。在代理打开的情况下，一般只能跑到300左右。关闭有1000个线程基本稳定通过。最多可以跑到1500左右。目前被列为最大“嫌疑人”

 

以  OneCoder 目前的知识构成来说，Netty并发的测试基本可以告一段落了。再简单的总结唠到几句：

1. 如果需要测试并发，可以考虑多进程，进程内多线程的方式测试服务端压力。
2. OneCoder 没有测试Netty最大可以支持多少并发，因为从目前测试的效果来看。（5个进程，每个进程1000线程，持续访问同一个服务），已经完全可以满足 OneCoder 的要求了。您也可以继续测试下去。
3. OneCoder 使用的是windows7 32位操作系统，在测试过程其实也修改了注册表中的若干参数，包括上面提到的两个。不知道是否起到了一定的作用，也就是是否使单进程可以支持的多线程数增加，或者服务端可以支持的连接数增加，您在测试的过程中，可以配合考虑这些参数。
4. 对于，connection refuse的具体原因， OneCoder 希望能随着自己知识的慢慢积累，找到其真正的答案。

如非特别注明，本站内容均为OneCoder原创，转载请务必注明作者和原始出处。
本文地址：http://www.coderli.com/netty-concurrency-problem-test-end