Tomcat连接器体系结构,线程池和异步servlet

Question

我想了解Tomcat的BIO和NIO连接器的线程模型.我正在引用可在此处找到的连接器的官方Tomcat 7文档.基于此,这是我所怀疑的:

• acceptorThread(s):这是一个或最多2个线程(如文档中所述),它只负责接受进入的连接.这可以使用acceptorThreadCount进行配置,并建议多个机器可以使用两个以上 -
  • 为什么是这样 ？
  • 这是否意味着同时打开的连接数量与服务器系统允许的cpus数量与打开文件描述符数量成比例？
• maxConnections(s):
  • 此设置与acceptCount之间的关系是什么,以及系统上打开的文件描述符的数量.
  • 为什么NIO连接器(10000)的默认值比BIO(= maxThreads)高得多？
• acceptCount:当所有请求处理线程都忙时,这是请求的队列.
  • 将请求放入此队列时,是否也为其分配了文件描述符？或者仅当请求被主动处理时,它是否使用文件描述符？
• 请求处理线程:此池中的线程数由maxThreads和minSpareThreads属性配置.
  • 这个线程池和acceptorThreads之间有什么关系？接受者线程是否会产生此池中的线程？
  • 据我所知,NIO模型对请求处理线程的效率高于BIO模型.它如何实现这种效率？
  • 正如我在各种来源中所读到的,NIO模型中的线程遵循每个请求范例的线程与BIO模型的每个连接范例的线程.此外,在NIO连接器模型中,实际请求处理被委托给不同的应用程序监视线程,而服务器的请求处理线程返回到线程池,以接受更多连接.那么,这是否意味着只有与服务器的连接具有HTTP Keep-Alive特性或者应用程序使用Servlet 3.0的异步处理功能时,NIO模型的好处才会明显？
• Servlet 3.0:
  • 使用Servlet 3.0时,应用程序servlet线程池的大小(相对于连接器线程池大小)应该达到最佳效率？
  • 当使用BIO模型和它们时,请问如何处理(假设连接器线程仍然使用每个连接模型的线程)会有什么不同吗？

请注意:关于tomcat的所有讨论7.

Answer 1

• acceptorThread(s):这是一个或最多2个线程(如文档中所述),它只负责接受进入的连接.这可以使用acceptorThreadCount进行配置,并建议多个机器可以使用两个以上 -

  为什么是这样 ？

接受连接是一种成本非常低的操作,因此将多个线程专用于此任务是没有意义的.

Does this imply that the number of simultaneous open connections 
scales with the number of cpus versus the number of open file descriptors 
allowed on the server system ?

不,它不是因为它在CPU方面是一个非常低成本的操作.对于文件描述符,每个接受的连接将使用文件描述符,因此服务器可以接受的最大连接数受限于可用文件描述符的数量.

• maxConnections(s):

  此设置与acceptCount之间的关系是什么,以及系统上打开的文件描述符的数量.

maxConnections不能高于系统上打开文件描述符的数量.请记住,其他进程也使用文件描述符,因此可能希望对可用文件描述符使用maxConnections保守,假设maxConnections <文件描述符/ 2.

Why is the default value for this so much higher for the NIO connector 
( 10000 ) than for the BIO ( = maxThreads ) ?

这是因为在NIO中,单个处理所有IO,而在BIO中,服务器需要创建/使用单独的每个线程连接.

• acceptCount:当所有请求处理线程都忙时,这是请求的队列.

  将请求放入此队列时,是否也为其分配了文件描述符？

是的,接受连接请求是正确的,但服务器尚未准备好提供请求,因此连接被放入队列中.这样做是为了防止TCP /堆栈超时连接请求,从客户端的角度来看,这些请求可能看起来像服务器.换句话说,服务器说'我在这里,一旦我有资源就会处理你的请求'.

或者仅当请求被主动处理时,它是否使用文件描述符？

不.

希望这可以帮助.

问候,

Slava Imeshev