SpringBoot maxConnections、maxThreads、acceptCount解析

 

maxConnections、maxThreads、acceptCount:
如果tomcat當前處理的請求數小於等於maxConnections，則acceptCount所對應的隊列會是空。即有3個窗口，2個人來，就不需要排隊
如果tomcat當前處理的請求數大於maxConnections，則新來的請求會放到隊列長度為acceptCount的隊列中。即有3個窗口，5個人來，就需要排隊
maxThreads是tomcat中實際處理請求的並發數，即同時可以處理幾個請求。 如果maxThreads=2，即3個窗口，后面只有2個人在處理

使用kill -9殺掉springboot應用后，立馬java -jar重啟，會報錯，需要等待一段時間才能啟動成功，
報錯的原因是：/tmp/tomcat-docbase.4749794910434376321.9086] is not valid
以下是詳細錯誤信息：

Caused by: org.apache.catalina.LifecycleException: Failed to start component [org.apache.catalina.webresources.StandardRoot@53001498]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:158) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4831) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4963) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
... 7 more
Caused by: java.lang.IllegalArgumentException: The main resource set specified [/tmp/tomcat-docbase.4749794910434376321.9086] is not valid
at org.apache.catalina.webresources.StandardRoot.createMainResourceSet(StandardRoot.java:725) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
at org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:686) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:152) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4831) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4963) ~[tomcat-embed-core-8.5.4.jar!/:8.5.4]
... 7 more
mealtime-report-[15:48:37:716] [ERROR] - org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:181) - A child container failed during start

 

[root@localhost tmp]# ls -dlt tomcat*
drwxr-xr-x 3 root root 4096 May 15 14:19 tomcat.2482651926943103152.4444
drwxr-xr-x 2 root root 4096 May 15 14:19 tomcat-docbase.1606353072223048027.4444
drwxr-xr-x 3 root root 4096 May 15 14:19 tomcat.6427937730432992105.4004
drwxr-xr-x 2 root root 4096 May 15 14:19 tomcat-docbase.9014354490424152602.4004
drwxr-xr-x 3 root root 4096 May 14 18:21 tomcat.365692316696650885.2000
drwxr-xr-x 2 root root 4096 May 14 18:21 tomcat-docbase.8871210702020412482.2000
drwxr-xr-x 3 root root 4096 May 14 18:21 tomcat.9194454391130879725.2222
drwxr-xr-x 2 root root 4096 May 14 18:21 tomcat-docbase.6449009990528406178.2222
drwxr-xr-x 3 root root 4096 May 11 16:31 tomcat.7533402776366547594.3333
drwxr-xr-x 2 root root 4096 May 11 16:31 tomcat-docbase.8347169054078560101.3333
drwxr-xr-x 3 root root 4096 May 11 16:31 tomcat.5755321441664547955.3004
drwxr-xr-x 2 root root 4096 May 11 16:31 tomcat-docbase.4368794759444711233.3004
drwxr-xr-x 3 root root 4096 May 11 16:31 tomcat.7487101127514666304.4444
drwxr-xr-x 2 root root 4096 May 11 16:31 tomcat-docbase.3505389582011000978.4444
drwxr-xr-x 3 root root 4096 May 11 16:30 tomcat.6483749742824168608.4004
drwxr-xr-x 2 root root 4096 May 11 16:30 tomcat-docbase.2936863713994400124.4004
drwxr-xr-x 3 root root 4096 May 11 16:30 tomcat.8814016287852028090.2000
drwxr-xr-x 2 root root 4096 May 11 16:30 tomcat-docbase.5759661693624441557.2000
drwxr-xr-x 3 root root 4096 May 11 16:30 tomcat.3084296173620137759.2222
drwxr-xr-x 2 root root 4096 May 11 16:30 tomcat-docbase.2913734529869658765.2222
drwxr-xr-x 3 root root 4096 May 11 16:30 tomcat.1261539854295462589.3333
drwxr-xr-x 2 root root 4096 May 11 16:30 tomcat-docbase.4327066414867055940.3333
drwxr-xr-x 3 root root 4096 May 11 16:30 tomcat.1652439996406851728.3004
drwxr-xr-x 2 root root 4096 May 11 16:30 tomcat-docbase.5233226104416503892.3004
drwxr-xr-x 3 root root 4096 May 11 11:38 tomcat.8505864110333115533.3333
drwxr-xr-x 2 root root 4096 May 11 11:38 tomcat-docbase.5036544091928181133.3333
drwxr-xr-x 3 root root 4096 May 11 11:37 tomcat.494020510980868278.3004
drwxr-xr-x 2 root root 4096 May 11 11:37 tomcat-docbase.468265602651303178.3004
drwxr-xr-x 3 root root 4096 May 11 11:36 tomcat.8093369488059063930.3004
drwxr-xr-x 2 root root 4096 May 11 11:36 tomcat-docbase.7679645853200594654.3004
drwxr-xr-x 3 root root 4096 May 11 11:31 tomcat.5040740781547956399.4444
drwxr-xr-x 2 root root 4096 May 11 11:31 tomcat-docbase.8256790475295084303.4444
drwxr-xr-x 3 root root 4096 May 11 11:31 tomcat.7344112750169248130.4004
drwxr-xr-x 2 root root 4096 May 11 11:31 tomcat-docbase.2016044219412775812.4004
drwxr-xr-x 3 root root 4096 May 11 11:30 tomcat.3866209351076068036.4444

 

 

 

 

 

 

 

 

site:tomcat.apache.org   maxConnections

 

Attribute	Description
acceptCount	The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

maxConnections

The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until the number of connections being processed falls below maxConnections at which point the server will start accepting and processing new connections again. Note that once the limit has been reached, the operating system may still accept connections based on the acceptCount setting. The default value is 8192. For NIO/NIO2 only, setting the value to -1, will disable the maxConnections feature and connections will not be counted.

maxThreads

The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1 to make clear that it is not used.

http://tomcat.apache.org/tomcat-9.0-doc/config/http.html

詳解：maxConnections、maxThreads、acceptCount

tomcat中maxConnections、maxThreads、acceptCount的具體含義是什么呢？參考官方文檔，對三者的含義說明如下：

一、accept-count：最大等待數

官方文檔的說明為：當所有的請求處理線程都在使用時，所能接收的連接請求的隊列的最大長度。當隊列已滿時，任何的連接請求都將被拒絕。accept-count的默認值為100。
詳細的來說：當調用HTTP請求數達到tomcat的最大線程數時，還有新的HTTP請求到來，這時tomcat會將該請求放在等待隊列中，這個acceptCount就是指能夠接受的最大等待數，默認100。如果等待隊列也被放滿了，這個時候再來新的請求就會被tomcat拒絕（connection refused）。

二、maxThreads：最大線程數

每一次HTTP請求到達Web服務，tomcat都會創建一個線程來處理該請求，那么最大線程數決定了Web服務容器可以同時處理多少個請求。maxThreads默認200，肯定建議增加。但是，增加線程是有成本的，更多的線程，不僅僅會帶來更多的線程上下文切換成本，而且意味着帶來更多的內存消耗。JVM中默認情況下在創建新線程時會分配大小為1M的線程棧，所以，更多的線程異味着需要更多的內存。線程數的經驗值為：1核2g內存為200，線程數經驗值200；4核8g內存，線程數經驗值800。

三、maxConnections：最大連接數

官方文檔的說明為：

這個參數是指在同一時間，tomcat能夠接受的最大連接數。對於Java的阻塞式BIO，默認值是maxthreads的值；如果在BIO模式使用定制的Executor執行器，默認值將是執行器中maxthreads的值。對於Java 新的NIO模式，maxConnections 默認值是10000。
對於windows上APR/native IO模式，maxConnections默認值為8192，這是出於性能原因，如果配置的值不是1024的倍數，maxConnections 的實際值將減少到1024的最大倍數。
如果設置為-1，則禁用maxconnections功能，表示不限制tomcat容器的連接數。
maxConnections和accept-count的關系為：當連接數達到最大值maxConnections后，系統會繼續接收連接，但不會超過acceptCount的值。

四、參數設置
（1）maxThreads的設置既與應用的特點有關，也與服務器的CPU核心數量有關。
通過前面介紹可以知道，maxThreads數量應該遠大於CPU核心數量；而且CPU核心數越大，maxThreads應該越大；應用中CPU越不密集（IO越密集），maxThreads應該越大，以便能夠充分利用CPU。
當然，maxThreads的值並不是越大越好，如果maxThreads過大，那么CPU會花費大量的時間用於線程的切換，整體效率會降低。
（2）maxConnections的設置與Tomcat的運行模式有關。如果tomcat使用的是BIO，那么maxConnections的值應該與maxThreads一致；如果tomcat使用的是NIO，maxConnections值應該遠大於maxThreads。
（3）通過前面的介紹可以知道，雖然tomcat同時可以處理的連接數目是maxConnections，但服務器中可以同時接收的連接數為maxConnections+acceptCount 。
acceptCount的設置，與應用在連接過高情況下希望做出什么反應有關系。
如果設置過大，后面進入的請求等待時間會很長；如果設置過小，后面進入的請求立馬返回connection refused。

https://blog.csdn.net/zzzgd_666/article/details/88740198

1.4.3 圖解：maxConnections、maxThreads、acceptCount關系

用一個形象的比喻，通俗易懂的解釋一下tomcat的最大線程數（maxThreads）、最大等待數（acceptCount）和最大連接數（maxConnections）三者之間的關系。

我們可以把tomcat比做一個火鍋店，流程是取號、入座、叫服務員，可以做一下三個形象的類比：
（1）acceptCount 最大等待數
可以類比為火鍋店的排號處能夠容納排號的最大數量；排號的數量不是無限制的，火鍋店的排號到了一定數據量之后，服務往往會說：已經客滿。
（2）maxConnections 最大連接數
可以類比為火鍋店的大堂的餐桌數量，也就是可以就餐的桌數。如果所有的桌子都已經坐滿，則表示餐廳已滿，已經達到了服務的數量上線，不能再有顧客進入餐廳了。
（3）maxThreads：最大線程數
可以類比為廚師的個數。每一個廚師，在同一時刻，只能給一張餐桌炒菜，就像極了JVM中的一條線程。

 

整個就餐的流程，大致如下：

（1）取號：如果maxConnections連接數沒有滿，就不需要取號，因為還有空余的餐桌，直接被大堂服務員領上餐桌，點菜就餐即可。如果 maxConnections 連接數滿了，但是取號人數沒有達到 acceptCount，則取號成功。如果取號人數已達到acceptCount，則拿號失敗，會得到Tomcat的Connection refused connect 的回復信息。
（2）上桌：如果有餐桌空出來了，表示maxConnections連接數沒有滿，排隊的人，可以進入大堂上桌就餐。
（3）就餐：就餐需要廚師炒菜。廚師的數量，比顧客的數量，肯定會少一些。一個廚師一定需要給多張餐桌炒菜，如果就餐的人越多，廚師也會忙不過來。這時候就可以增加廚師，一增加到上限maxThreads的值，如果還是不夠，只能是拖慢每一張餐桌的上菜速度，這種情況，就是大家常見的“上一道菜吃光了，下一道菜還沒有上”尷尬場景。

 

maxConnections、maxThreads、acceptCount關系圖如下

 https://www.cnblogs.com/crazymakercircle/p/11748214.html

 

對tomcat連接器3個屬性maxConnections、maxThreads、acceptCount的理解：

maxConnections描述紅色部分說明當連接數達到最大值后，系統會繼續接收連接但不會超過acceptCount的值。

理解：

我們可以把tomcat比做一個電影院，流程是取號、買票、觀影，acceptCount比作前廳(容納取到號的人)、maxConnections比作大廳（容納買到票的人）、maxThreads比作影廳（可以理解一個影廳只容納一個人，因為一個線程同時只處理一個請求），以下場景是針對已達到maxConnections最大值來討論的

1）取號：如果前廳人數已達到acceptCount，則拿號失敗，會得到Connection refused connect的回復信息。反之則會進入前廳，等待買票。

2）買票：當大廳人數小於maxConnections時，前廳的人就可以進入大廳

3）觀影：當影廳的人離開時，大廳的部分人能進入影廳，一般來講大廳的容量要遠大於影廳的數量。

本文是針對apache-tomcat-7.0.55做的測試。

tomcat server.xml配置參數

    <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" acceptCount="2" maxConnections="10" maxThreads="2"
               connectionTimeout="20000"
               redirectPort="8443" />

Servlet的代碼：休眠20秒

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
InputStream is = request.getInputStream();
System.out.println(new Date()+":"+is+"開始");
Thread.sleep(20000);
System.out.println(new Date()+":"+is+"結束");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}

 

一個請求或一個connection的生命周期：可以簡單的理解為從doGet或doPost開始response響應結束。

使用JMeter測試，線程數20，連接超時時間10s，響應超時時間30s

測試結果：

察看結果數：
第1秒：8個請求得到響應數據：Connection refused connect
第20秒：2個請求正常響應
第30秒：剩余10個請求得到響應數據：Readtimed out

tomcat日志：

打印12組開始結束的日志，說明tomcat會處理acceptCount+maxConnections的請求，說明只要取到號，有足夠的耐心，就肯定能夠看到電影。
————————————————
版權聲明：本文為CSDN博主「mazi2004」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/kaka20099527/article/details/53285348