java – Tomcat连接器架构,线程池和异步servlet

的连接器的官方Tomcat 7文档.基于此,这是我所怀疑的：

> acceptorThread(s)：这是一个或最多2个线程(如文档中提到的),它只负责接受即将进行的连接.这可以使用acceptorThreadCount进行配置,建议多个CPU可以使用两个以上的机器 –

为什么会这样？

>这是否意味着同时打开连接的数量会随着服务器系统允许的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.

• acceptorThread(s): This is a single or at the most 2 threads (as

  mentioned in the doc) which is responsible only for accepting

  in-coming connections. This can be configured using

  acceptorThreadCount, and it’s suggested that more than two can be used

  for a multi-cpu machine –

  why is this ?

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

06000

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

• maxConnections(s) :

  What is the relation between this setting and acceptCount and the number

  of open file descriptors on the system.

Or is it only when a request is being actively processed, does it consume a file descriptor ?