Brief analysis of Tomcat NIO configuration

"Respecting the original article excerpt from: http://blog.csdn.net/yaerfeng/article/details/7679740"

There are 3 modes of operation for Tomcat. Modify their run mode. 3 modes of operation is successful, you can see his startup console, or start the log. or log in to their default page http://localhost:8080/to see the server status.

1) bio

The default mode, performance is very low, without any optimization processing and support.

2) NiO

Using Java's asynchronous IO Care technology, no blocking IO technology.

Want to run in this mode, directly modify the connector node in the Server.xml, modify the protocol to

Once started, it can take effect.

3) Apr

Installation is the most difficult, but from the operating system level to solve the asynchronous IO problem, greatly improve performance.

Apr and native must be installed and the APR will be supported directly on the launch. The following modifications are superfluous, only to expand the knowledge, but you still need to install APR and native

such as NiO modify mode, modify protocol to Org.apache.coyote.http11.Http11AprProtocol

Tomcat 6.X implements the specifications of the JCP servlet 2.5 and JSP2.1, and includes many other useful features that make it a development
and a solid platform for deploying Web apps and Web services.
NIO (no-blocking I/O) from JDK 1.4, the NIO API acts as a buffer-based API and can provide non-blocking I/O operations
Be introduced.


As a Java implementation of an open source Web server, Tomcat is almost the first choice for Web developers to develop and test, with many other business services
The developer of the device will also prefer Tomcat as a development time, and when deployed, publish the application on a business Server. also have
Many commercial applications are deployed on Tomcat, and Tomcat carries its core applications. But a lot of developers are confused, why in their own should
When using Tomcat as a platform, the server becomes very busy and the number of concurrent users exceeds a certain amount, and it quickly appears
Connection refuse's error. But many commercial applications are deployed on Tomcat and run unharmed.

One of the big reasons is that a well-configured Tomcat will use APR (Apache portable Runtime) and Apr is
At the core of the Apache HTTP server2.x, it is a highly portable local library that uses high-performance uxin I/O operations, low-performance
Java IO operations, but Apr may be a bit more difficult for many Java developers, and on many OS platforms you may need to re-edit
Translation of Apr. But since Tomcat6.0, Java developers can easily use NIO technology to improve Tomcat's concurrency processing power.
But why NiO can improve Tomcat's concurrency, let's take a look at the differences between Java traditional IO and Java NIO.

Java Traditional IO operations are blocking (blocking I/O), if there is a socket programming basis, you will be exposed to blocked sockets and
Non-clogging socket, blocked socket is in the accept, read, write and other IO operations, if there is no eligible funding
Source, do not return immediately, wait until there is a resource. Instead of blocking the socket is when the select is executed, when there is no resource
When a resource is met, a signal is returned, and then the program can perform operations such as accept, read, write, etc., generally to
that if you use a plug socket, usually we usually open a thread accept socket, when reading the socket request, open a
A separate thread to handle the socket request; If a non-clogging socket is used, usually there is only one thread, starting with the Select shape,
When a signal is available, it can be processed by multiplexing (multiplexing) technology to a specified thread pool to process the request, but
After the original thread continues the select state. The simplest multiplexing technology can be implemented through the Java Pipeline (pipe). In other words, if
When the client's concurrent requests are large, we can process these requests with fewer threads than the client's concurrent requests, which do not
And immediately processed requests are blocked in the Java pipeline or queue, waiting for the thread pool to be processed. The request sounds complicated, in this frame.
In the world of architecture, there are now many excellent NIO architectures that are easy for developers to use, such as Grizzly,apache Mina, etc.
And so on, if you are interested in how to write high-performance Web servers, you can read the source code.

To put it simply, blocking io (bio) on a Web server is a more important difference from NIO, and when we use bio, we tend to
Multiple threads are introduced for each Web request, and each Web request is a separate thread, so the number of threads goes up as soon as the concurrency is up.
, the CPU is busy with thread switching, so bio is not suitable for high-throughput, highly scalable Web servers, whereas NIO uses single-threaded (single
CPU) or use only a small number of multithreading (multi-CPU) to accept the socket, and the thread pool to handle blocked in the pipe or queue, please
In this case, the Web server can handle the request as long as the OS can accept the TCP connection. Greatly improves the Web server's available
Flexibility.

Let's take a look at the configuration, you just need to make the following changes to the HTTP connector in Server.xml

<connector port= "8080" protocol= "http/1.1"
connectiontimeout= "20000"
redirectport= "8443"/>
Switch
<connector port= "8080" protocol= "Org.apache.coyote.http11.Http11NioProtocol"
connectiontimeout= "20000"
redirectport= "8443"/>

Then start the server and you will see the ORG.APACHE.COYOTE.HTTP11.HTTP11NIOPROTOCOL start message indicating that NiO has started. Please refer to the official configuration documentation for additional configuration.

Enjoy it.

Finally, a simple comparison of the three types of Tomcat connector is posted on official documents,

 java Blocking Connector java Nio Blocking Connector APR connectorclassname http11protocol                     Http11nioprotocol Http11aprprotocoltomcat Version 3.x 4.x 5.x 6.x 6.x           5.5.x 6.xSupport Polling NO YES yespolling Size                     N/a unlimited-restricted by mem unlimitedread HTTP Request Blocking                       Blocking blockingread HTTP Body Blocking Blocking Blockingwrite HTTP Response Blocking Blocking blockingssl Support J Ava SSL Java SSL Opensslssl handshake Blocking Non B Locking Blockingmax Connections maxthreads See polling size See PO Lling size 

If the reader has a socket programming basis, should be exposed to plug socket and non-blocking socket, blocked socket is in the accept, read, write and other IO operations, if there is no eligible resources, not immediately return, Wait until there are resources. Instead of plugging the socket is when the execution of the Select, when there is no resources to block, when there is a resource to return a signal, then the program can execute accept, read, write, and so on, this time, these operations are immediately completed, and immediately return. The Windows Winsock is different, can be bound to a eventhandle, can also be bound to an HWND, when a resource arrives, the event is emitted, then the IO operation is completed immediately, return immediately. In general, if you use a plug socket, usually we open a thread to accept the socket, when there is a socket link, open a separate thread to handle the socket; If a non-clogging socket is used, usually there is only one thread, starting with the Select State 　　 　　, process immediately when there is a signal, then proceed to select State. As most people say, plugging a socket is better than a non-clogging socket. However, a small number of people do not think so, such as the Indy Project (Delphi is a better network package), it is to use multi-threaded + plug socket mode. 　　 　　In addition, plugging the socket is easier to understand than the non-clogging socket, which conforms to the general human mind and is relatively easy to program. NiO is actually similar to the above situation. In Jdk1.4,sun, where NiO is one of the major improvements in Java performance. Java's IO operations are concentrated in the java.io package, which is a stream-based blocking API (i.e. Bio,block IO). For most applications, such APIs are easy to use, however, some applications with higher performance requirements, especially for service-side applications, often require a more efficient way to process IO. 　　 　　From JDK 1.4, the NIO API is introduced as a buffer-based, and can provide non-blocking O-operation of the API (i.e., nio,non-blocking IO).  　　 　　A more important difference between bio and NiO is that when we use bio, we tend to introduce multiple threads, each connecting a single thread, while NIO uses a single thread or uses only a small number of multiple threads, each of which is shared by each connection. This time, the problem comes out: Our very many Java applications are using threadlocal, such as JSF Facecontext, hibernateSession management, STRUTS2 context management, and so on, almost all frameworks are more or less applied to threadlocal. 　　 　　Wouldn't it be earth-shattering if there were conflicts? Finally, I found the answer in Tomcat6 's document (http://tomcat.apache.org/tomcat-6.0-doc/aio.html). According to the above instructions, it should be TOMCAT6 application of NIO is used only when processing send, receive information, that is, tomcat6 or traditional multithreaded servlet, I drew the following two diagram to list the difference: TOMCAT5: Client Connection arrives Traditional seversocket.accept receive connection, remove a thread from the thread pool, read the text and parse the HTTP protocol, and generate ServletRequest, servletresponse in the thread, 　　 　　The servlet that takes out the request is executed on that thread, and the thread sends the contents of the Servletresponse to the client connection, and closes the connection. I used to understand. Tomcat6 after use of NIO: Client connection arrival, NiO receive connection, NIO use polling to read text and resolve HTTP protocol (single thread), Generate ServletRequest, servletresponse 　　 　　, the servlet, which takes out the request, sends the contents of the Servletresponse to the client connection, and closes the connection directly in the execution of this servlet, this thread. Actual TOMCAT6: NiO receive connection--Client connection arrival--The use of a polling method to read text and parse the HTTP protocol (single thread), Generate ServletRequest, Servletresponse, 　 　　 　　 　　Remove the requested servlet, from the thread pool, and send the contents of the Servletresponse to the client connection, and close the connection when the thread executes the servlet. As can be seen, the difference between bio and NiO also leads to a different time to enter the client processing thread: TOMCAT5 into the client thread immediately after accepting the connection, parsing the HTTP protocol in the client thread, and TOMCAT6 after parsing the HTTP protocol into multi-threading, in addition, Tomcat6 is also out of the client thread's environment earlier than 5. 　　 　　The difference between the actual tomcat6 and my previous guess focuses on how to deal with the servlet problem. In fact, even if the threadlocal problem is thrown aside, I understand that the idea of TOMCAT6 using only one thread is actually a different line. We all have experience: Servlets are based on bio, and there are blockages during execution, such as reading files, database operations, and so on. 　　　 　　 　　TOMCAT6 uses NIO, but it is not possible to ask the servlet to use NIO, and once there is a blockage, the efficiency will fall sharply.  So, the final conclusion of course is Tomcat6 servlet inside, threadlocal can still use, there is no conflict.

Brief analysis of Tomcat NIO configuration