Java NIO Framework Netty Tutorial (13) Concurrent access test (bottom)

• In the previous section ("Java NIO Framework Netty Tutorial (12) Concurrent access Test (middle)"), we tested the Netty concurrency scenarios from all angles. In this section, we will focus on the last issue mentioned in the previous section. In the case of multi-threaded concurrent access, there will be

  Warning: EXCEPTION, implement One.coder.netty.chapter.eight.ObjectClientHandler.exceptionCaught () for proper Handling.
  Java.net.ConnectException:Connection Refused:no Further information
  
  Error warning.
  
  Prior to the Onecoder layer suspected that the number of ports is not enough, so also prepared a set of changes to the operating system port limit configuration.
  
  A) windows–
  1. Open registry: regedit
  2, Hkey_local_machine\system\currentcontrolset\ Services\Tcpip\Parameters
  3. New DWORD value, name:tcptimedwaitdelay,value:0 (decimal) –> set to 0
  4. New DWORD value, name:maxuserport,value:65534 (decimal) –> set maximum number of connections 65534
  5. Restart the system
  
  b) linux–
  1. View the relevant options/sbin/sysctl-a|grep NET.IPV4.TCP_TW
  Net.ipv4.tcp_tw_reuse = 0
  #表示开启重用. Allows time-wait sockets to be re-used for new TCP connections, which defaults to 0, which means shutdown;
  net.ipv4.tcp_tw_recycle = 0
  #表示开启TCP连接中TIME-wait Sockets Fast Recovery, default is 0, indicates off
  2, modify the vi/etc/sysctl.conf
  Net.ipv4.tcp_tw_reuse = 1
  Net.ipv4.tcp_tw_recycle = 1
  3. Make kernel parameters effective sysctl-p
  
  

  This set of configurations plays a significant effect when testing the Restlet framework concurrency.

  
  Then, this time, even if Onecoder modifies the configuration, there is no significant increase in concurrent connections. Onecoder decided to change his mind, initiating multiple processes to continue access to the same service to prove that the previous connection rejection is due to the client multithreading concurrency itself (in fact, Onecoder has been very suspicious of this problem) or service-side connection processing problems.
  
  Modified the client to launch the message code, so that it within its thread, and constantly send information to the server.

  
  View Sourceprint?01./**02.* 发送Object03.*04.* @param channel05.* @author lihzh06.* @alia OneCoder07.* @blog http://www.coderli.com08.*/09.private void sendObject(final Channel channel) {10.new Thread(new Runnable() {11. 12.@Override13.public void run() {14.// TODO Auto-generated method stub15.for (;;) {16.Command command = new Command();17.command.setActionName("Hello action.");18.channel.write(command);19.try {20.Thread.sleep(1000);21.} catch (InterruptedException e) {22.e.printStackTrace();23.}24.}25.}26.}).start();27.}
  

  Start multiple clients, effect

  
  

  Sure enough, the server can handle all requests without a link rejection when the number of individual processes is reasonably controlled. The total number of connections easily reaches 4,5k. (Onecoder Note: Previously more than 1000 were error prone.) This is just a test of a situation where there was no way to support it before, and the maximum pressure value was not tested. ）
  
  For testing Netty service-side pressure, such a test, onecoder think can play a full effect, there is reference value. Because even though there is no limit to the single-process network connection, the number of threads that can be started by a single process is limited, and efficiency is bound to be affected. Therefore, for concurrent testing, Onecoder thinks it can be used in the above way.
  
  For a single-process multithreaded, the problem of rejecting the connection. is thrown in the native method Checkconnect in Sun.nio.ch.SocketChannelImple. This should be closely related to the operating system. Onecoder does not test under Linux, but guesses that under Linux, the above parameters can work, which is more than the number of concurrent threads that can be opened under Windows. Of course it's just speculation.
  
  For Windows, Onecoder can open multiple threads of concurrency, and this data is very unstable in the context of the environment. At the very beginning, it was 1000 threads, 350 threads of success. Later, Onecoder suspected that the program started too much, especially the network-related programs will affect the test results, close a lot of programs. As a result, multiple 1000 threads are successfully connected.
  
  Onecoder carefully check, suddenly found Onecoder use proxifier this agent. In the case of the agent opened, generally only run to about 300. The shutdown has 1000 threads that basically stabilize through. You can run up to about 1500. Currently listed as the largest "suspect"
  
  To onecoder current knowledge composition, Netty concurrency test can be almost over. A brief summary of the chatter to a few words:

  1, if you need to test concurrency, you can consider multi-process, in-process multi-threaded way to test the service pressure.

  2, Onecoder no test netty maximum can support how much concurrency, because from the current test results. (5 processes, 1000 threads per process, continuous access to the same service), have fully met the requirements of Onecoder. You can also go on with your test.

  3, Onecoder using Windows7 32-bit operating system, in the testing process has also modified several parameters in the registry, including the above mentioned two. Do not know whether to play a certain role, that is, whether the single process can support the increase in number of threads, or the server can support the increase in the number of connections, you in the process of testing, you can consider these parameters.

  4, for the specific reasons of connection refuse, Onecoder hope that with their knowledge of the gradual accumulation of the real answer to find.

Java NIO Framework Netty Tutorial (13) Concurrent access test (bottom)