Tomcat容器併發性能涉及概念及配置

Tomcat線程池併發調優

版本：tomcat7

官方文檔：Apache Tomcat 7 Configuration

tomcat性能優化主要從啓動參數和server入手，server則主要是從excutor和connector着手，網上文章一大堆，魚龍混雜，大部分文章自己都解釋不清。最好的辦法是去看官方文檔。

對於大型應用，如果用tomcat的話，應該考慮在參數優化後進行壓測，找到單機能承受的最大壓力，然後考慮橫向擴展應用集羣。

下面對參數調優中的幾項關鍵參數做說明（參照官方文檔）。

---

server.xml

excutor

• maxThreads

  線程池裏面的最大活躍線程數

• maxQueueSize

  (int) The maximum number of runnable tasks that can queue up awaiting execution before we reject them. Default value is Integer.MAX_VALUE

  在被服務器拒絕之前能夠排隊等待運行的最大任務數。默認是Integer.MAX_VALUE

  這個參數既然默認值都是最大值了，那麼非必要情況不用配置這個參數。

• minSpareThreads

  (int) The minimum number of threads (idle and active) always kept alive, default is 25

  最小空閒線程數，默認25個。結合maxIdleTime，可以理解爲至少存在25個空閒線程隨時待命。

• maxIdleTime

  (int) The number of milliseconds before an idle thread shutsdown, unless the number of active threads are less or equal to minSpareThreads. Default value is 60000(1 minute)

  理解爲空閒線程的最大存活時間（默認一分鐘），一個進程空閒時間超過這個時間後，會被關閉。除非當前線程池裏面的線程數已經小於等於minSpareThreads。

Connector

針對較爲複雜且流程處理耗時較大的系統，首先把protocol換成nio。

org.apache.coyote.http11.Http11NioProtocol - non blocking Java connector

BIO、NIO、APR三者特點如下：

BIO更適合處理簡單流程，如程序處理較快可以立即返回結果。

NIO更適合後臺需要耗時完成請求的操作，如程序接到了請求後需要比較耗時的處理這已請求，所以無法立即返回結果，這樣如果採用BIO就會佔用一個連接，而使用NIO後就可以將此連接轉讓給其他請求，直至程序處理完成返回爲止。

APR可以大大提升Tomcat對靜態文件的處理性能，同時如果你使用了HTTPS方式傳輸的話，也可以提升SSL的處理性能。

• 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.

  線程池的最大線程數，表示tomcat最多能起這麼多個線程

• 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 varies by connector type. For BIO the default is the value of maxThreads unless an Executor is used in which case the default will be the value of maxThreads from the executor. For NIO the default is 10000. For APR/native, the default is 8192.

  If set to a value of -1, the maxConnections feature is disabled and connections are not counted.

  最大連接數，相當於給定時間段內服務器能接受並運行的併發請求數。當併發請求達到這個數值後，服務器會繼續接受請求但不運行（放到acceptCount隊列，這個隊列滿後就不再接受請求）。

• minSpareThreads

  The minimum number of threads always kept running. This includes both active and idle threads. If not specified, the default of 10 is used. 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.

• 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.

  等待隊列的size，默認值100。當線程池裏邊的可用線程全部被使用時，再有請求儘量就會排隊到這個隊列，直到又有可用線程能夠消費。當這個隊列也滿了後，如果還有請求進來就會被拒絕（connection refused等）。

• acceptorThreadCount

  The number of threads to be used to accept connections. Increase this value on a multi CPU machine, although you would never really need more than 2. Also, with a lot of non keep alive connections, you might want to increase this value as well. Default value is 1.

  用於接收連接的線程數。對於多核CPU，可以增加這個值，非keep-alive的連接也可以增加這個值。默認爲1.可以設置爲cpu的線程數。

---

對併發性能影響最關鍵的連個參數：maxThreads and acceptCount:

maxThreads是指Tomcat線程池做多能起的線程數
maxConnections則是Tomcat一瞬間做多能夠處理的併發連接數。比如maxThreads=1000，maxConnections=800，假設某一瞬間的併發時1000，那麼最終Tomcat的線程數將會是800，即同時處理800個請求，剩餘200進入隊列“排隊”，如果acceptCount=100，那麼有100個請求會被拒掉。

注意：根據前面所說，只是併發那一瞬間Tomcat會起800個線程處理請求，但是穩定後，某一瞬間可能只有很少的線程處於RUNNABLE狀態，大部分線程是TIMED_WAITING，如果你的應用處理時間夠快的話。所以真正決定Tomcat最大可能達到的線程數是maxConnections這個參數和併發數，當併發數超過這個參數則請求會排隊，這時響應的快慢就看你的程序性能了。

JVM菜鳥進階高手之路七（tomcat調優以及tomcat7、8性能對比）

情況1：接受一個請求，此時tomcat起動的線程數沒有到達maxThreads，tomcat會起動一個線程來處理此請求。

情況2：接受一個請求，此時tomcat起動的線程數已經到達maxThreads，tomcat會把此請求放入等待隊列，等待空閒線程。

情況3：接受一個請求，此時tomcat起動的線程數已經到達maxThreads，等待隊列中的請求個數也達到了acceptCount，此時tomcat會直接拒絕此次請求，返回connection refused

一般的服務器操作都包括量方面：1計算（主要消耗cpu），2等待（io、數據庫等）

第一種極端情況，如果我們的操作是純粹的計算，那麼系統響應時間的主要限制就是cpu的運算能力，此時maxThreads應該儘量設的小，降低同一時間內爭搶cpu的線程個數，可以提高計算效率，提高系統的整體處理能力。

第二種極端情況，如果我們的操作純粹是IO或者數據庫，那麼響應時間的主要限制就變爲等待外部資源，此時maxThreads應該儘量設的大，這樣才能提高同時處理請求的個數，從而提高系統整體的處理能力。此情況下因爲tomcat同時處理的請求量會比較大，所以需要關注一下tomcat的虛擬機內存設置和linux的open file限制。

TOMCAT優化，提高併發能力

具體配置

性能測試

測試工具：Jmeter、jvisualvm.exe

在jmeter 500線程模擬訪問的時候，用jvisualvm觀察線程情況和GC情況，控制jmeter 500模擬線程不變，分別測試不同組tomcat server有關線程的配置參數。通過觀察對於單個tomcat，過高的線程數會導致cpu性能過多的消耗在頻繁的上下文切換和創建及回收線程資源上。過低的線程數則不能承受併發，產生大量的連接失敗的情況。根據多次壓測結果、GC分析和線程分析推測，單機tomcat併發數應控制在800左右比較合理。

配置參數：

<Executor name="tomcatThreadPool" 
		  namePrefix="catalina-exec-" 
		  prestartminSpareThreads="true" 
		  maxThreads="500" 
		  minSpareThreads="50"
		  maxIdleTime="10000" />

<Connector executor="tomcatThreadPool"
		   port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="20000"
           acceptCount="400"
           acceptorThreadCount="4"
           maxConnections="800"
           compression="on"
           enableLookups="false"
           redirectPort="8443" />