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 ?