【架構性能分析（2）】Tomcat 配置優化

前言：

作爲一個系統管理員（運維/架構師），我們時刻關注服務的變化情況，今天分享一篇關於Tomcat 配置優化相關性的文章。

Tomcat主配文件Service.xml解說

Server：元素是整個配置文件的根元素。表示整個Catalina容器。

• className：實現了org.apache.catalina.Server接口的類名，標準實現類是org.apache.catalina.core.StandardServer類。
• Port：Tomcat服務器監聽用於關閉Tomcat服務器的命令（必須）
• Shutdown：發送到端口上用於關閉Tomcat服務器的命令。

例：

<Serverport="8005" shutdown="SHUTDOWN">

Connector：元素連接器，負責接收客戶的請求，以及向客戶端回送響應的消息。

HTTP連接器-屬性：

• allowTrace：是否允許HTTP的TRACE方法，默認爲false
• emptySessionPath：如果設置爲true，用戶的所有路徑都將設置爲/，默認爲false。
• enableLookups：調用request、getRemoteHost()執行DNS查詢，以返回遠程主機的主機名，如果設置爲false，則直接返回IP地址。
• maxPostSize：指定POST方式請求的最大量，沒有指定默認爲2097152。
• protocol：值必須爲HTTP1.1，如果使用AJP處理器，該值必須爲AJP/1.3
• proxyName：如這個連接器正在一個代理配置中被使用，指定這個屬性，在request.getServerName()時返回
• redirectPort：如連接器不支持SSL請求，如收到SSL請求，Catalina容器將會自動重定向指定的端口號，讓其進行處理。
• scheme：設置協議的名字，在request.getScheme()時返回，SSL連接器設爲”https”，默認爲”http”
• secure：在SSL連接器可將其設置爲true，默認爲false
• URIEncoding：用於解碼URL的字符編碼，沒有指定默認值爲ISO-8859-1
• useBodyEncodingForURI：主要用於Tomcat4.1.x中，指示是否使用在contentType中指定的編碼來取代URIEncoding，用於解碼URI查詢參數，默認爲false
• xpoweredBy：爲true時，Tomcat使用規範建議的報頭表明支持Servlet的規範版本，默認爲false
• acceptCount：當所有的可能處理的線程都正在使用時，在隊列中排隊請求的最大數目。當隊列已滿，任何接收到的請求都會被拒絕，默認值爲10
• bufferSize：設由連接器創建輸入流緩衝區的大小，以字節爲單位。默認情況下，緩存區大的大小爲2048字節
• compressableMimeType：MIME的列表，默認以逗號分隔。默認值是text/html，text/xml，text/plain
• compression：指定是否對響應的數據進行壓縮。off：表示禁止壓縮、on：表示允許壓縮（文本將被壓縮）、force：表示所有情況下都進行壓縮，默認值爲off
• connectionTimeout：設置連接的超時值，以毫秒爲單位。默認值爲60000=60秒
• disableUploadTimeOut：允許Servlet容器，正在執行使用一個較長的連接超時值，以使Servlet有較長的時間來完成它的執行，默認值爲false
• maxHttpHeaderSize：HTTP請求和響應頭的最大量，以字節爲單位，默認值爲4096字節
• maxKeepAliveRequest：服務器關閉之前，客戶端發送的流水線最大數目。默認值爲100
• maxSpareThreads：允許存在空閒線程的最大數目，默認值爲50
• minSpareThreads：設當連接器第一次啓協創建線程的數目，確保至少有這麼多的空閒線程可用。默認值爲4
• port：服務端套接字監聽的TCP端口號，默認值爲8080（必須）
• socketBuffer：設Socket輸出緩衝區的大小（以字節爲單位），-1表示禁止緩衝，默認值爲9000字節
• toNoDelay：爲true時，可以提高性能。默認值爲true
• threadPriority：設JVM中請求處理線程優先級。默認值爲NORMAL-PRIORITY
  例：

<Connector
port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />

AJP連接器-屬性：用於將Apache與Tomcat集成在一起，當Apache接收到動態內容請求時，通過在配置中指定的端口號將請求發送給在此端口號上監聽的AJP連接器組件。

• backlog：當所有可能的請求處理線程都在使用時，隊列中排隊的請求最大數目。默認爲10，當隊列已滿，任何請求都將被拒絕
• maxSpareThread：允許存在空閒線程的最大數目，默認值爲50
• maxThread：最大線程數，默認值爲200
• minSpareThreads：設當連接器第一次啓動時創建線程的數目，確保至少有這麼多的空閒線程可用，默認值爲4
• port：服務端套接字的TCP端口號，默認值爲8089（必須）
• topNoDelay：爲true時，可以提高性能，默認值爲true
• soTimeout：超時值

例：

<!—Define an AJP1.3 Connector on port 8089-->
<Connector port="8089" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

Engine-元素：

爲特定的Service處理所有的請示。每個Service只能包含一個Engine元素，它負責接收和處理此Service所有的連接器收到的請求，向連接發回響應，並最終顯示在客戶端。至少有一個元素，必須至少有一個屬性的名字與defaultHost指定的名字相匹配。

• className：實現org.apache.catalina.Engine接口，默認實現類爲org.apache.catalina.core.StandardEngine類
• defaultHost：默認主機名，值必須與的name值相匹配
• name：指定Engine的邏輯名字（必須）
• jvmRoute：在負載勻衡中使用的標識符，必須唯一

例：

<Engine name="Cataline" defaultHost="localhst">

Host元素：

表示一個虛擬主機，爲特定的虛擬主機處理所有請求

• appBase：設定應用程序的基目錄，絕對路徑或相對於%CATALINA_HOME%的路徑名
• autoDeploy：指示Tomcat運行時，如有新的WEB程序加開appBase指定的目錄下，是否爲自動佈署，默認值爲true
• className：實現了org.apache.catalina.Host接口的類，標準實現類爲org.apache.catalina.core.StandardHost類
• deployOnStartup：Tomcat啓動時，是否自動部署appBase屬性指定目錄下所有的WEB應用程序，默認值爲true
• name：虛擬主機的網絡名（必須）

標準Host實現類org.apahce.catalina.core.StandardHost支持的附加屬性：
deployXML：爲false將不會解析WEB應用程序內部的context.xml，默認值爲true
unPackWARs：虛擬主機指定臨時讀寫使用的目錄的路徑名，不設，Tomcat會在%CATALINA_HOME%/work目錄下提供一個合適的目錄。

例：

<Host name="localhst" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

配置虛擬主機：

<Hostname="xxx" appBase="c:/test">
    <Contentpath="" docBase="e:/abe"/>
</Hostname>

context元素：

一個WEB應用程序，處理當前WEB應用程序的所有請求，每一個必須使用唯一的上下文路徑。

• className：實現了org.apache.catalina.Context接口的類，標準實現類org.apache.catalina.core.StandardContext類
• cookies：是否將Cookie應用於Session，默認值爲true
• crossContext：是否允許跨域訪問，爲true時，在程序內調用ServletContext.getContext()方法將返回一個虛擬主機上其它web程序的請求調度器。默認值爲false，調 徑用getContext()返回爲null
• docBase：絕對路徑或相對於Host的appBase 屬性的相對路徑
• privileged：爲true，允許Web應用程序使用容器的Servlet
• path：指定上下文路徑。一個虛擬主機中，上下文路徑必須唯一
• reloadable：爲true，Tomcat運行時，如果WEB-INF/classes和WEB-INF/lib目錄中有改變，Tomcat會自動重新加載該WEB應用程序。雖方便，但開銷也大，默認值爲false，我們在調用可以打開，發佈後再關閉。
• cacheMaxSize：靜態資源緩存最大值，以KB爲單位，默認值爲10240KB
• cachingAllowed：是否允許靜態資源緩存，默認爲true
• caseSensitive：默認爲true,資源文件名大小寫敏感，如果爲false大小寫不敏感
• unpackWAR：默認爲true
• workDir：爲WEB應用程序內部的Servlet指定臨時讀寫的目錄路徑名。如沒有設置，則Tomcat會在%CATALINA_HOME%/work目錄下提供一個合適的目錄

例：

<Content path="/abc" docBase="d:/xyz" reloadable="true" />

Tomcat線程性能解說

在使用tomcat時，經常會遇到連接數、線程數之類的配置問題，要真正理解這些概念，必須先了解Tomcat的連接器（Connector）。

在前面詳解Tomcat配置文件server.xml ，Connector是Tomcat的主要功能，是接收連接請求，創建Request和Response對象用於和請求端交換數據；然後分配線程讓Engine（也就是Servlet容器）來處理這個請求，並把產生的Request和Response對象傳給Engine。當Engine處理完請求後，也會通過Connector將響應返回給客戶端。

可以說，Servlet容器處理請求，是需要Connector進行調度和控制的，Connector是Tomcat處理請求的主幹，因此Connector的配置和使用對Tomcat的性能有着重要的影響。這篇文章將從Connector入手，討論一些與Connector有關的重要問題，包括NIO/BIO模式、線程池、連接數等。

根據協議的不同，Connector可以分爲HTTP Connector、AJP Connector等，本文只討論HTTP Connector。

一、Nio、Bio、APR

1、Connector的protocol

Connector在處理HTTP請求時，會使用不同的protocol。不同的Tomcat版本支持的protocol不同，其中最典型的protocol包括BIO、NIO和APR（Tomcat7中支持這3種，Tomcat8增加了對NIO2的支持，而到了Tomcat8.5和Tomcat9.0，則去掉了對BIO的支持）。

BIO是Blocking IO，顧名思義是阻塞的IO；NIO是Non-blocking IO，則是非阻塞的IO。而APR是Apache Portable Runtime，是Apache可移植運行庫，利用本地庫可以實現高可擴展性、高性能；Apr是在Tomcat上運行高併發應用的首選模式，但是需要安裝apr、apr-utils、tomcat-native等包。

2、如何指定protocol

Connector使用哪種protocol，可以通過元素中的protocol屬性進行指定，也可以使用默認值。

指定的protocol取值及對應的協議如下：

HTTP/1.1：默認值，使用的協議與Tomcat版本有關
org.apache.coyote.http11.Http11Protocol：BIO
org.apache.coyote.http11.Http11NioProtocol：NIO
org.apache.coyote.http11.Http11Nio2Protocol：NIO2
org.apache.coyote.http11.Http11AprProtocol：APR

如果沒有指定protocol，則使用默認值HTTP/1.1，其含義如下：在Tomcat7中，自動選取使用BIO或APR（如果找到APR需要的本地庫，則使用APR，否則使用BIO）；在Tomcat8中，自動選取使用NIO或APR（如果找到APR需要的本地庫，則使用APR，否則使用NIO）。

3、BIO/NIO有何不同

無論是BIO，還是NIO，Connector處理請求的大致流程是一樣的：

在accept隊列中接收連接（當客戶端向服務器發送請求時，如果客戶端與OS完成三次握手建立了連接，則OS將該連接放入accept隊列）；在連接中獲取請求的數據，生成request；調用servlet容器處理請求；返回response。爲了便於後面的說明，首先明確一下連接與請求的關係：連接是TCP層面的（傳輸層），對應socket；請求是HTTP層面的（應用層），必須依賴於TCP的連接實現；一個TCP連接中可能傳輸多個HTTP請求。

在BIO實現的Connector中，處理請求的主要實體是JIoEndpoint對象。JIoEndpoint維護了Acceptor和Worker：Acceptor接收socket，然後從Worker線程池中找出空閒的線程處理socket，如果worker線程池沒有空閒線程，則Acceptor將阻塞。其中Worker是Tomcat自帶的線程池，如果通過配置了其他線程池，原理與Worker類似。

在NIO實現的Connector中，處理請求的主要實體是NIoEndpoint對象。NIoEndpoint中除了包含Acceptor和Worker外，還是用了Poller，處理流程如下圖所示。

Acceptor接收socket後，不是直接使用Worker中的線程處理請求，而是先將請求發送給了Poller，而Poller是實現NIO的關鍵。Acceptor向Poller發送請求通過隊列實現，使用了典型的生產者-消費者模式。在Poller中，維護了一個Selector對象；當Poller從隊列中取出socket後，註冊到該Selector中；然後通過遍歷Selector，找出其中可讀的socket，並使用Worker中的線程處理相應請求。與BIO類似，Worker也可以被自定義的線程池代替。

通過上述過程可以看出，在NIoEndpoint處理請求的過程中，無論是Acceptor接收socket，還是線程處理請求，使用的仍然是阻塞方式；但在“讀取socket並交給Worker中的線程”的這個過程中，使用非阻塞的NIO實現，這是NIO模式與BIO模式的最主要區別（其他區別對性能影響較小，暫時略去不提）。而這個區別，在併發量較大的情形下可以帶來Tomcat效率的顯著提升：

目前大多數HTTP請求使用的是長連接（HTTP/1.1默認keep-alive爲true），而長連接意味着，一個TCP的socket在當前請求結束後，如果沒有新的請求到來，socket不會立馬釋放，而是等timeout後再釋放。如果使用BIO，“讀取socket並交給Worker中的線程”這個過程是阻塞的，也就意味着在socket等待下一個請求或等待釋放的過程中，處理這個socket的工作線程會一直被佔用，無法釋放；因此Tomcat可以同時處理的socket數目不能超過最大線程數，性能受到了極大限制。而使用NIO，“讀取socket並交給Worker中的線程”這個過程是非阻塞的，當socket在等待下一個請求或等待釋放時，並不會佔用工作線程，因此Tomcat可以同時處理的socket數目遠大於最大線程數，併發性能大大提高。

二、3個參數：acceptCount、maxConnections、maxThreads

再回顧一下Tomcat處理請求的過程：在accept隊列中接收連接（當客戶端向服務器發送請求時，如果客戶端與OS完成三次握手建立了連接，則OS將該連接放入accept隊列）；在連接中獲取請求的數據，生成request；調用servlet容器處理請求；返回response。

相對應的，Connector中的幾個參數功能如下：

1、acceptCount

accept隊列的長度；當accept隊列中連接的個數達到acceptCount時，隊列滿，進來的請求一律被拒絕。默認值是100。

2、maxConnections

Tomcat在任意時刻接收和處理的最大連接數。當Tomcat接收的連接數達到maxConnections時，Acceptor線程不會讀取accept隊列中的連接；這時accept隊列中的線程會一直阻塞着，直到Tomcat接收的連接數小於maxConnections。如果設置爲-1，則連接數不受限制。

默認值與連接器使用的協議有關：NIO的默認值是10000，APR/native的默認值是8192，而BIO的默認值爲maxThreads（如果配置了Executor，則默認值是Executor的maxThreads）。

在windows下，APR/native的maxConnections值會自動調整爲設置值以下最大的1024的整數倍；如設置爲2000，則最大值實際是1024。

3、maxThreads

請求處理線程的最大數量。默認值是200（Tomcat7和8都是的）。如果該Connector綁定了Executor，這個值會被忽略，因爲該Connector將使用綁定的Executor，而不是內置的線程池來執行任務。

maxThreads規定的是最大的線程數目，並不是實際running的CPU數量；實際上，maxThreads的大小比CPU核心數量要大得多。這是因爲，處理請求的線程真正用於計算的時間可能很少，大多數時間可能在阻塞，如等待數據庫返回數據、等待硬盤讀寫數據等。因此，在某一時刻，只有少數的線程真正的在使用物理CPU，大多數線程都在等待；因此線程數遠大於物理核心數纔是合理的。

換句話說，Tomcat通過使用比CPU核心數量多得多的線程數，可以使CPU忙碌起來，大大提高CPU的利用率。

4、參數設置

（1）maxThreads的設置既與應用的特點有關，也與服務器的CPU核心數量有關。通過前面介紹可以知道，maxThreads數量應該遠大於CPU核心數量；而且CPU核心數越大，maxThreads應該越大；應用中CPU越不密集（IO越密集），maxThreads應該越大，以便能夠充分利用CPU。當然，maxThreads的值並不是越大越好，如果maxThreads過大，那麼CPU會花費大量的時間用於線程的切換，整體效率會降低。

（2）maxConnections的設置與Tomcat的運行模式有關。如果tomcat使用的是BIO，那麼maxConnections的值應該與maxThreads一致；如果tomcat使用的是NIO，那麼類似於Tomcat的默認值，maxConnections值應該遠大於maxThreads。

（3）通過前面的介紹可以知道，雖然tomcat同時可以處理的連接數目是maxConnections，但服務器中可以同時接收的連接數爲maxConnections+acceptCount 。acceptCount的設置，與應用在連接過高情況下希望做出什麼反應有關係。如果設置過大，後面進入的請求等待時間會很長；如果設置過小，後面進入的請求立馬返回connection refused。

三、線程池Executor

Executor元素代表Tomcat中的線程池，可以由其他組件共享使用；要使用該線程池，組件需要通過executor屬性指定該線程池。

Executor是Service元素的內嵌元素。一般來說，使用線程池的是Connector組件；爲了使Connector能使用線程池，Executor元素應該放在Connector前面。Executor與Connector的配置舉例如下：

<Executor name="tomcatThreadPool" namePrefix ="catalina-exec-" maxThreads="150" minSpareThreads="4" />
<Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" acceptCount="1000" />

Executor的主要屬性包括：

• name：該線程池的標記
• maxThreads：線程池中最大活躍線程數，默認值200（Tomcat7和8都是）
• minSpareThreads：線程池中保持的最小線程數，最小值是25
• maxIdleTime：線程空閒的最大時間，當空閒超過該值時關閉線程（除非線程數小於minSpareThreads），單位是ms，默認值60000（1分鐘）
• daemon：是否後臺線程，默認值true
• threadPriority：線程優先級，默認值5
• namePrefix：線程名字的前綴，線程池中線程名字爲：namePrefix+線程編號

四、查看當前狀態

上面介紹了Tomcat連接數、線程數的概念以及如何設置，下面說明如何查看服務器中的連接數和線程數。

查看服務器的狀態，大致分爲兩種方案：（1）使用現成的工具，（2）直接使用Linux的命令查看。

現成的工具，如JDK自帶的jconsole工具可以方便的查看線程信息（此外還可以查看CPU、內存、類、JVM基本信息等），Tomcat自帶的manager，收費工具New Relic等。下圖是jconsole查看線程信息的界面：

下面說一下如何通過Linux命令行，查看服務器中的連接數和線程數。

1、連接數

假設Tomcat接收http請求的端口是8083，則可以使用如下語句查看連接情況：

netstat –nat | grep 8081

結果如下所示：

[root@test_houtai ~]# netstat -nat |grep 8081
tcp        0  0 0.0.0.0:8081          0.0.0.0:*      LISTEN      
tcp        1  0 47.93.112.243:55978   47.93.112.243:8081 CLOSE_WAIT  
tcp        1  0 47.93.112.243:60260   47.93.112.243:8081 CLOSE_WAIT 

可以看出，有一個連接處於listen狀態，監聽請求；除此之外，還有4個已經建立的連接（ESTABLISHED）和2個等待關閉的連接（CLOSE_WAIT）。

2、線程

ps命令可以查看進程狀態，如執行如下命令：

ps –e | grep java

結果如下圖：

[root@houtai_tools ~]# ps -ef|grep java
root     28915 28707  0 11:54 pts/0    00:00:00 grep java

可以看到，只打印了一個進程的信息；28915是線程id，java是指執行的java命令。這是因爲啓動一個tomcat，內部所有的工作都在這一個進程裏完成，包括主線程、垃圾回收線程、Acceptor線程、請求處理線程等等。

通過如下命令，可以看到該進程內有多少個線程；其中，nlwp含義是number of light-weight process。

ps –o nlwp 27989

[root@houtai_tools ~]# ps -o nlwp 16014
NLWP
  62

可以看到，該進程內部有62個線程；但是並沒有排除處於idle狀態的線程。要想獲得真正在running的線程數量，可以通過以下語句完成：

ps -eLo pid ,stat | grep 27989 | grep running | wc -l

其中ps -eLo pid ,stat可以找出所有線程，並打印其所在的進程號和線程當前的狀態；兩個grep命令分別篩選進程號和線程狀態；wc統計個數。其中，ps -eLo pid ,stat | grep 27989輸出的結果如下：

[root@test_houtai ~]# ps -eLo pid,stat |grep 31761
31761 Sl
31761 Sl
31761 Sl
31761 Sl
31761 Sl
31761 Sl
31761 Sl
31761 Sl
31761 Sl

圖中只截圖了部分結果；Sl表示大多數線程都處於空閒狀態。

Tomcat性能優化方案

待續。。。。。。