In the first two sections, we looked at both the bio and NIO modes of tomcat implementation.
Bio's way, is the traditional thread, a request mode, that is, when 1000 requests come over, if Tomcat set the maximum number of accept threads of 500, then the first batch of 500 threads directly into the thread pool to execute, While the remaining 500 blocks are blocked in the socket buffer at the kernel location of the server-side operating system based on the limit of accept, until the first 500 threads have finished processing,acceptor components are then progressively put in.
Analysis of the benefits of this model of bio, you can allow a request in the CPU rotation time slice switch to maximize the execution, if the business request is not a long time transaction, usually in a time slice will certainly be able to finish the current request, this is quite high efficiency, Because it reduces the most time-consuming and the most headache of the thread context switch;1. However, if the transaction executes for a long time, such as waiting for an IO database operation, the worker thread will be switched on and off according to the CPU rotation, because the number of requests is many in large concurrency, so we have to set a very high number of accept threads, So from the CPU's cost of resources, even 70% of the time wasted in the thread switch, and there is no real time to do the request processing and business, this is the first problem. 2. Second, the creation and release of each link of bio will need to be repeated, for example, when a socket comes in, the properties of its socketoptions are usually set, including one by one corresponding to the configuration in various connector. In addition to the above-mentioned socket establishment, many request channel resources initialization has to be recreated, is not reused, this is the second problem. 3. Finally, the Bio-mode network IO Blocking wait is going to makeAccept thread productivity is much lower. Therefore, based on these 3 problems, especially the last one, the model of NIO is introduced.
the structure of NIO is divided into three thread pools, where you can comb it again:1.Acceptor is specifically connected to the socket request, and when the discovery and request comes in, the Tomcat-based configurationSocketoptions and some of the properties of the set up, packaged into Socketchannel, that is, NIO's socket channel abstraction, plug into the pollerevent directly into the queue;2.Poller threads are fetched from the queuepollerevent, callingPoller thread itself holds the selector selector, registeringSocketchannel to the currentselector The selector, and thento do selectkey work, soacceptor passed it over.events of interest in the Socketchannel are polled, and when the receive event is received, the Op_read event needs to be registered orOp_write Events, whenOp_read Event orwhen the Op_write event occurs, the worker thread pool begins to be invoked;3. The work thread pool is socketprocessor, this is the specific worker threads,Socketprocessor's task is to poller the thread from the Socketchannel channel polling packets, parse, pass to the back end of the handler for HTTP parsing, parse out the Request,reponse object, Call Coyoteadapter directly to the back-end container, passingMapper, mapped to the corresponding business servlet. You can see that fromSocketprocessor until the end of the business servlet implementation, which is a thread that is a worker thread.
Compare the architecture of Tomcat's bio, because there is noSelector Polling operation, so there is no poller thread, the role of the acceptor thread in bio still is to simply handle the socket and attribute wrapper, and then throw the socket directly into the worker thread. NiO is the equivalent of a single thread pool, which, in process terms, should be one more procedure, but it is caused by the mechanism of the event-triggering of NiO itself,acceptor threads do not need to set too much, so from the number of threads, greatly reduce the frequency of thread switching, followed by event-based triggering, willThe network IO latency in acceptor thread execution efficiency is minimized, greatly improvingacceptor The execution efficiency of the thread. From these two points, Tomcat's NIO has improved on the first and third issues in the three problems of bio analyzed earlier, in particular the third one, which has been comprehensively upgraded.
However, for the first problem in bio, the work thread pool has been running for a long time from back-end transactions, and running at a peak value, constantly switching, this problem, the NIO channel has no way of processing, this is determined by the business, NIO can only guarantee that the reduction isacceptor the number of thread threads, the business help is also powerless, if you want to improve the efficiency of this part, it will need to modify the application, optimize the JDBC and database, or the business segment to do, so that the transaction time as far as possible to control within a manageable scope.
For the second question, neither the pure NiO nor the Bio channel can be resolved, but the reuse of the link is updated in the HTTP protocol, and in HTTP1.1, the keepalive is added to the HTTP request header:keep-alive:timeout=5, max=100
Timeout: Expiration time 5 seconds (corresponding to httpd.conf parameters are: keepalivetimeout);Max is a shared reuse that can withstand up to 100 requests,is a new connection in timeout time, and Max will automatically minus 1 until 0, forcing it to break.
The server-side configuration of the corresponding Tomcat:
KeepAliveTimeout: Indicates how long Tomcat keeps the connection until the next request comes up. This means that the connection will persist if the client continues to request it and the expiration time is exceeded.
Maxkeepaliverequests: Indicates the maximum number of requests supported for this connection. Connections that exceed the number of requests are also closed (a connection:close header is returned to the client).
If you configure the above, you can solve the second problem of bio above, when the first request in a page, after the connection can be reused this socket or socketchannel, no more accept three handshake or SSL handshake, Effectively drives the efficiency of the overall Tomcat's time chain, whileThe addition of the keepalive attribute, measured by bio and NiO comparisons, is equivalent to amplifying the advantages of NIO, which results in a significantly higher test result than the bio-level. This is the reason why the Tomcat successor version defaults to NiO in the current http1.1 protocol, and if there is nokeepalive attribute added, in most scenarios, NiO did not pull the gap with bio too big, and even some scenes, Tomcat's bio model is higher than NIO;
There is no point in comparing performance here, because performance testing is a test in different application types, different hardware environments, different soft armor versions, and even different JDK performance differences are very large, objective factors, and Tomcat's Web server is currently in enterprise applications or Internet applications, Is the small part of the chain of time accounted for, and even some long transaction processing chain, Tomcat this piece accounted for less than 1%, of course, for learning and research, higher and faster and stronger is the purpose of technical pursuit, this is another matter.
The following will be analyzed in detailkeepalive Implementation, there are apr,nio2 two channels of implementation, please look forward to.
From for notes (Wiz)
C.bio connector vs. NIO connectors
