What is the difference between Tomcat BIO Connector and NIO Connector?

Question

I would like to know the insides of the NIO tomcat connector. How exactly are threads used when we create a servlet that implements CometProcessor? Is it another thread for each connection?

From what I'm reading, the conversation goes as follows

• Client connects to servlet

• Servlet freezes before connecting until any data is available to the connected client

• When the data is ready, the server writes to httpResponse and resets it. Does this actually disconnect the connection?

• The client sends another request, which the server hangs again.

How many threads are used when this happens?

Answer 1

NIO and Comet are completely unrelated: you can mix and match them.

Using the NIO connector (or APR in this case) allows you to process more requests with fewer threads due to the streaming model. See http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison for a comparison between connectors.

Comet (and Websocket) have a completely different scheduling model, which requires a different application architecture and provides higher bandwidth in a different way.

The script that you ask in your question is a typical model lock with one thread per request. In step 4, the Java BIO connector (which runs through Tomcat 7 by default) will continue to wait for additional requests for the existing connector - for keepalive HTTP requests. If the client does not establish Connection:close in the previous request and does not close the connection, the thread will hang until the keepalive timeout is reached. If you use the NIO connector, the stream will return to the thread pool immediately after sending the response, and you will not "waste" the stream on keepalive requests that will never arrive.

Comet / Websocket works in a completely different way, passing a message to a specially written servlet (and optional filters), and threads are used only when there are messages to send or data to be written.

UPDATE 2016-08-19

Tomcat 8.5 and 9.0 completely reset the BIO connector. This is due to the fact that many of the new APIs and technologies (for example, Websocket) require non-blocking semantics, and creating a non-blocking service on top of the blocking API is very difficult. The code needed to complete this work made the rest of the Tomcat code very ugly, etc., and so it was decided to completely abandon the BIO connector. Therefore, only NIO, NIO2, and APR-based connectors are available for Tomcat 8.5 onwards.

Please note that with Tomcat 8.5 and 9.0, Comet support has been disabled. Use of the comet should be replaced by Websocket, which is a more standard protocol.

Answer 2

NIO uses fewer streams, which means less tcp / ip port usage.

You know that the port is from 1 to 65534, so we can say that NIO can achieve higher TPS (transactions per second) than BIO

I tested both protocols :HTTP/1.1 and org.apache.coyote.http11.Http11NioProtocol with the same web project, with the same host and with the same server.xml, but with the protocol.

Use jmeter for test.

I set 1000 threads to start the request when HTTP / 1.1 in a few minutes, the host use port is more than 30000, and TPS is only 300!

When org.apache.coyote.http11.Http11NioProtocol, the maximum port usage score never goes over 3000, and the tps is over 1200!

Answer 3

Adding late to this discussion. In this context, performance comparisons between IO locking and asynchronous NIO are an excellent read on "The old way to write servers is new . " As a result, it was shown below that the thread on the connection model is better to execute and easy to write compared to the NIO version - contrary to popular belief.

Answer 4

Here are two good articles on the NIO connector, if it helps someone to consider the differences between BIO (request processing must accept the stream), and NIO (request processing is transferred to another workflow) in Tomcat.

• NIO Connector via Tomcat Expert Website
• Tomcat Connector Overview (PDF)