Shulou(Shulou.com)06/02 Report--

This article shares with you the content of a sample analysis of the NIO model in Tomcat. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

First, the interpretation of Icord O reuse model.

The NIO of Tomcat is implemented on the basis of Istroke O reuse. We must be clear about this point, or our discussion will not be on the same logical line. The following diagram has generally seen the knowledge of the UNIX O model, which comes from UNIX Network programming. There are blocking Imax O, non-blocking Imax O reuse (select/poll/epoll), signal-driven Imax O and Asynchronous Imax O. This article is about Ihammer O reuse.

IO reuse .png

Let's start with user mode and kernel mode. To put it bluntly, if the thread is executing user code, the current thread is in user mode, and if the thread is executing code in the kernel, the current thread is in kernel state. At a deeper level, the operating system divides the privilege level of the code into four levels.

But modern operating systems only use levels 0 and 3. The switch between 0 and 3 is the switch between user mode and kernel state. For more details, please refer to in-depth understanding of the computer operating system. The Istroke O reuse model is synchronous non-blocking, where non-blocking refers to the read and write of Imax O, which corresponds to the recvfrom operation, because the data packet is ready and does not need to be blocked.

It is said to be synchronous because the execution is executed in a thread. Sometimes, it is also said to be blocking, which actually means blocking on the select and having to wait until network events such as read and write are ready. Sometimes we say that channel O multiplexing is multiplexing. In this case, multiplexing refers to N connections, each connection corresponds to one channel, or multiplexing means multiple connections.

Reuse means that multiple connections reuse one thread or a small number of threads (in Tomcat, it is Math.min (2 Magi Runtime.getRuntime (). AvailableProcessors ().

The network events mentioned above have four network events: connection-ready, receive-ready, read-ready, and write-ready. IPot O reuse is mainly achieved through Selector multiplexers, and the above description can be understood in conjunction with the following figure.

Selector diagram .png

2. TOMCAT's support for IO model

Tomcat supports IO type diagrams. Png

Tomcat has supported the NIO model since 6, and the implementation is based on the java.nio package of JDK. You can see here that it is Blocking for read body and response body. This is highlighted in section 6.3 source code reading.

III. Configuration and use of NIO in TOMCAT

Configure protocol= "org.apache.coyote.http11.Http11NioProtocol" in the Connector node. The default maximum number of connections under the Http11NioProtocol protocol is 10000. You can also modify the value of maxConnections. At the same time, we can set the maximum number of threads maxThreads. Here, the maximum number of threads is the size of the thread pool of Excutor.

There is actually no maxConnections in BIO mode, and even the configuration will not take effect. MaxConnections in BIO mode is the same size as maxThreads because it is an one-request-one-thread mode.

IV. Interpretation of NioEndpoint component diagram

Tomcatnio consists of .png

The most important thing for us to understand tomcat's nio is to understand NioEndpoint. It consists of LimitLatch, Acceptor, Poller, SocketProcessor and Excutor5.

LimitLatch is the connection controller, which is responsible for maintaining the calculation of the number of connections. The default is 10000 in nio mode. When this threshold is reached, the connection request is rejected. Acceptor is responsible for receiving the connection, which is executed by 1 thread by default, registering the requested event with the event list.

There is a Poller responsible for polling, and the number of Poller threads is the core number of cpu Math.min (2meme Runtime.getRuntime (). AvailableProcessors ()). Poller generates SocketProcessor of ready events and hands them to Excutor for execution. The size of the Excutor thread pool is the value of the maxThreads that we configured on the Connector node.

In the thread of Excutor, the http request is read from socket, parsed into a HttpServletRequest object, dispatched to the appropriate servlet and completed the logic, and then the response is sent back to client through socket.

In the process of reading data from socket and writing data to socket, instead of registering OP_READ or OP_WRITE events to the main Selector as a typical non-blocking NIO, read and write directly through socket, which is done by blocking, but in timeout control, NIO's Selector mechanism is used, but this Selector is not the main Selector maintained by the Poller thread, but the Selector maintained in the BlockPoller thread, called the secondary selector. The detailed source code can be found in Section 6.3.

5. NioEndpoint execution sequence diagram

Tomcatnio sequence diagrams. Png

In the next section of NioEndpoint source code interpretation, we will find the corresponding code for steps 1-11 in turn.

VI. Interpretation of NioEndpoint source code

6.1. Initialize

Whether it is BIO or NIO, the connection limit is initialized and cannot be increased indefinitely. The default is 10000 in NIO mode.

6.2. Step interpretation

Below we focus on the process related to NIO, which is divided into 11 steps, corresponding to the steps in the sequence diagram above.

Step 1: bind the IP address and port and set the ServerSocketChannel to block.

Why is it set to blocking? we talk about non-blocking all the time. The original design of Tomcat is mainly for convenience of operation. So it's the same as in BIO mode. It's just that under BIO, what's returned here is

SocketChannel is returned here under Socket,NIO.

Step 2: start the receiving thread

Step 3:ServerSocketChannel.accept () receives the new connection

Step 4: set the received link channel to non-blocking

Step 5: construct the NioChannel object

Step 6:register registers to the polling thread

Step 7: construct the PollerEvent and add it to the event queue

Step 8: start the polling thread

Step 9: remove the new PollerEvent from the queue and register with Selector

Step 10:Selector.select ()

Step 11: construct the SocketProcessor based on the selected SelectionKey and submit it to the request processing thread

Introduction to NioBlockingSelector and BlockPoller

One thing I didn't describe in the sequence diagram above is NioSelectorPool, an inner class, because it's easier to understand the nio of tomcat without including it in the sequence diagram.

After having the above foundation, we will talk about the NioSelectorPool class, and we must know its role for the NIO with a deeper understanding of Tomcat. A NioSelecPool object is maintained in the NioEndpoint object, and a BlockPoller thread is maintained in the NioSelectorPool, which is the logic of NIO based on the secondary Selector.

Take, after executing servlet, getting response, writing data to socket as an example, the final process of writing calls the write method of NioBlockingSelector. The code is as follows:

In other words, when socket.write () returns 0, the network state is unstable, and the socket registers the OP_WRITE event to the secondary Selector, and the BlockPoller thread polls the secondary Selector continuously until it is found that the write state of the socket is restored, and the Worker thread is informed to continue writing the socket action through the countdown counter. Take a look at the code logic of the BlockSelector thread:

The main purpose of using this secondary Selector is to reduce switching between threads, while also reducing the burden on the primary Selector.

VII. About performance

The following report is a result of our stress test, is it different from what we imagined? There is almost no difference. In fact, NIO optimizes the read and write of I BIO O, and there is virtually no difference between BIO and NIO if the bottleneck is not here, such as when the number of bytes transferred is very small.

The advantage of NIO is that it uses a small number of threads to hold a large number of connections. In addition, in the process of stress testing, we encounter errors at the beginning of a short period of time in NIO mode, because general stress testing tools are based on a long connection, that is to say, if 1000 concurrency is simulated, then 1000 connections are established at the same time, and the next time the request is sent based on the previous 1000 connections, and the NIO processing of TOMCAT is taken over by Poller threads. Its number of threads is generally equal to the number of cores of CPU, and if there are a large number of concurrency in an instant, POLLER will be unable to deal with it immediately.

Pressure test 1.jpeg

Pressure test 2.jpeg

Thank you for reading! This is the end of the article on "sample Analysis of NIO Model in Tomcat". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.