默認參數
注： Connector 通常在%HOME_TOMCAT%/conf/servser.xml 文件內
# 正常參數 <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
配置參數調試
# 優化參數 <Connector port="8080" protocol="HTTP/1.1" maxThreads="1000" minSpareThreads="100" acceptCount="1000" maxConnections="1000" connectionTimeout="20000" maxHttpHeaderSize="8192" tcpNoDelay="true" compression="on" compressionMinSize="2048" disableUploadTimeout="true" redirectPort="8443" enableLookups="false" URIEncoding="UTF-8" />
參數詳解
- 1）port
- 注：代表Tomcat端口號，默認8080。
- 2）protocol
- 注：協議類型，可選類型有4種，BIO（阻塞型IO），NIO，NIO2和APR。
# BIO BIO(Blocking I/O) 阻塞式I/O操作，傳統的Java I/O操作(即java.io包及其子包)。Tomcat在默認情況下，是以bio模式運行的，bio模式是三種運行模式中性能最低的一種。BIO配置采用默認即可。 BIO更適合處理簡單流程，如程序處理較快可以立即返回結果。簡單項目及應用可以采用BIO。 # NIO NIO(New I/O)是Java SE 1.4及后續版本提供的一種新的I/O操作方式(即java.nio包及其子包)。Java nio是一個基於緩沖區、非阻塞I/O操作的Java API它擁有比傳統I/O操作(bio)更好的並發運行性能。 NIO更適合后台需要耗時完成請求的操作，如程序接到了請求后需要比較耗時的處理這已請求，所以無法立即返回結果，這樣如果采用BIO就會占用一個連接，而使用NIO后就可以將此連接轉讓給其他請求，直至程序處理完成返回為止。 # APR APR(Apache Portable Runtime/Apache可移植運行時)，是Apache HTTP服務器的支持庫。你可以簡單地理解為:Tomcat將以JNI的形式調用 Apache HTTP服務器的核心動態鏈接庫來處理文件讀取或網絡傳輸操作，從而大大地提高 Tomcat對靜態文件的處理性能。 APR可以大大提升Tomcat對靜態文件的處理性能，同時如果你使用了HTTPS方式傳輸的話，也可以提升SSL的處理性能。 # 修改方式 //BIO protocol="HTTP/1.1" //NIO protocol="org.apache.coyote.http11.Http11NioProtocol" //NIO2 protocol="org.apache.coyote.http11.Http11Nio2Protocol" //APR protocol="org.apache.coyote.http11.Http11AprProtocol"
- 3）maxThreads
- 注：連接器創建處理請求線程的最大數目，處理同事請求的最大數目，默認值為200。
如果一個執行器與此連接器關聯，則忽略此屬性，因為該屬性將被忽略，所以該連接器將使用執行器而不是一個內部線程池來執行任務。maxThreads是一個重要的配置屬性，maxThreads配置的合理直接影響了Tomcat的相關性能。maxThreads並不是配置的越大越好，事實上你即使配置成999999也是沒有用的，因為這個最大值是受操作系統及相關硬件所制約的，並且最大值並不一定是最優值，所以我們追尋的應該是最優值而不是最大值。 QPS（Query Per Second）：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准。我們常常使用 QPS值來衡量一個服務器的性能。 QPS = 並發數 / 平均響應時間 並發數 = QPS * 平均響應時間 一個系統吞吐量通常由QPS、並發數兩個因素決定，每套系統的這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。所謂吞吐量這里可以理解為每秒能處理請求的次數。 所以選擇一個合理的 maxThreads值，其實並不是那么容易的事。因為過多的線程只會造成，更多的內存開銷，更多的CPU開銷，但是對提升QPS確毫無幫助；找到最佳線程數后通過簡單的設置，可以讓web系統更加穩定，得到最高，最穩定的QPS輸出。
# 獲取最佳maxThreads的最佳值 （1）通過線上系統不斷使用和用戶的不斷增長來進行性能測試，觀察QPS，響應時間，這種方式會在爆發式增長時系統崩潰，如雙12等。 （2）根據公式計算，服務器端最佳線程數量=((線程等待時間+線程cpu時間)/線程cpu時間) * cpu數量，這種方式有時會被誤導，因為某些系統處理環節可能會耗時比較長，從而影響公式的結果。 （3）單、多用戶壓力測試，查看CPU的消耗，然后直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳線程數量，這種方式理想場景比較適用，實際情況會比這個復雜的多。 （4）根據系統的自身情況調整，如硬件限制，系統限制，程序處理能力限制等。 （5）定期修改為不同的 maxThreads值，看服務器響應結果及用戶反應。 # QPS和線程數的關系 （1）在最佳線程數量之前，QPS和線程是互相遞增的關系，線程數量到了最佳線程之后，QPS持平，不在上升，甚至略有下降，同時相應時間持續上升。 （2）同一個系統而言，支持的線程數越多（最佳線程數越多而不是配置的線程數越多），QPS越高。 # QPS和響應時間的關系 （1）對於一般的web系統，響應時間一般有CPU執行時間+IO等待時間組成。 （2）CPU的執行時間減少，對QPS有實質的提升，IO時間的減少，對QPS提升不明顯。如果要想明顯提升QPS，優化系統的時候要着重優化CPU消耗大戶。
- 4）minSpareThreads
- 注：線程的最小運行數目，這些始終保持運行。如果未指定，默認值為10。
- 5）acceptCount
- 注：最大隊列長度。一般與maxThreads相同，默認為100。
當所有可能的請求處理線程都在使用時傳入連接請求的最大隊列長度。如果未指定，默認值為100。一般是設置的跟 maxThreads一樣或一半，此值設置的過大會導致排隊的請求超時而未被處理。所以這個值應該是主要根據應用的訪問峰值與平均值來權衡配置。
- 6）maxConnections
- 注：在任何給定的時間內，服務器將接受和處理的最大連接數。當這個數字已經達到時，服務器將接受但不處理，等待進一步連接。NIO與NIO2的默認值為10000，APR默認值為8192。
- 7）connectionTimeout
- 注：當請求已經被接受，但未被處理，也就是等待中的超時時間。單位為毫秒，默認值為60000。通常情況下設置為30000。
- 8）maxHttpHeaderSize
- 注：請求和響應的HTTP頭的最大大小，以字節為單位指定。如果沒有指定，這個屬性被設置為8192（8 KB）。
- 9）tcpNoDelay
- 注：如果為true，服務器socket會設置TCP_NO_DELAY選項，在大多數情況下可以提高性能。缺省情況下設為true。
- 10）compression
- 注：是否啟用gzip壓縮，默認為關閉狀態。這個參數的可接受值為“off”（不使用壓縮），“on”（壓縮文本數據），“force”（在所有的情況下強制壓縮）。
- 11）compressionMinSize
- 注：如果compression="on"，則啟用此項。被壓縮前數據的最小值，也就是超過這個值后才被壓縮。如果沒有指定，這個屬性默認為“2048”（2K），單位為byte。
- 12）disableUploadTimeout
- 注：這個標志允許servlet Container在一個servlet執行的時候，使用一個不同的，更長的連接超時。最終的結果是給servlet更長的時間以便完成其執行，或者在數據上傳的時候更長的超時時間。如果沒有指定，設為false。
- 13）enableLookups
- 注：關閉DNS反向查詢。
- 14）URIEncoding
- 注：URL編碼字符集。