Tomcat並發優化
1.調整連接器connector的並發處理能力
在Tomcat 配置文件 server.xml 中的 <Connector ... /> 配置中
1.參數說明
maxThreads 客戶請求最大線程數
minSpareThreads Tomcat初始化時創建的 socket 線程數
maxSpareThreads Tomcat連接器的最大空閑 socket 線程數
minProcessors：最小空閑連接線程數，用於提高系統處理性能，默認值為 10
maxProcessors：最大連接線程數，即：並發處理的最大請求數，默認值為 75
acceptCount：允許的最大連接數，應大於等於 maxProcessors ，默認值為 100
enableLookups：是否反查域名，取值為： true 或 false 。為了提高處理能力，應設置為 false
redirectPort 在需要基於安全通道的場合，把客戶請求轉發到基於SSL 的 redirectPort 端口
acceptAccount 監聽端口隊列最大數，滿了之后客戶請求會被拒絕（不能小於maxSpareThreads ）
connectionTimeout：網絡連接超時，單位：毫秒。設置為 0 表示永不超時，這樣設置有隱患的。通常可設置為30000 毫秒。
URIEncoding URL統一編碼
其中和最大連接數相關的參數為maxProcessors 和 acceptCount 。如果要加大並發連接數，應同時加大這兩個參數。
web server允許的最大連接數還受制於操作系統的內核參數設置，通常 Windows 是 2000 個左右， Linux 是1000 個左右。
2.Tomcat中的配置示例
<Connector port="9027"
protocol="HTTP/1.1"
maxHttpHeaderSize="8192"
maxThreads="1000"
minSpareThreads="100"
maxSpareThreads="1000"
minProcessors="100"
maxProcessors="1000"
enableLookups="false"
URIEncoding="utf-8"
acceptCount="1000"
redirectPort="8443"
disableUploadTimeout="true"/>
Tomcat緩存優化
tomcat的maxThreads、acceptCount（最大線程數、最大排隊數）
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="800" acceptCount="1000"/>
tomcate -->config --> server.xml
其中最后兩個參數意義如下：
maxThreads：tomcat起動的最大線程數，即同時處理的任務個數，默認值為200
acceptCount：當tomcat起動的線程數達到最大時，接受排隊的請求個數，默認值為100
這兩個值如何起作用，請看下面三種情況
情況1：接受一個請求，此時tomcat起動的線程數沒有到達maxThreads，tomcat會起動一個線程來處理此請求。
情況2：接受一個請求，此時tomcat起動的線程數已經到達maxThreads，tomcat會把此請求放入等待隊列，等待空閑線程。
情況3：接受一個請求，此時tomcat起動的線程數已經到達maxThreads，等待隊列中的請求個數也達到了acceptCount，此時tomcat會直接拒絕此次請求，返回connection refused
maxThreads如何配置
一般的服務器操作都包括量方面：1計算（主要消耗cpu），2等待（io、數據庫等）
第一種極端情況，如果我們的操作是純粹的計算，那么系統響應時間的主要限制就是cpu的運算能力，此時maxThreads應該盡量設的小，降低同一時間內爭搶cpu的線程個數，可以提高計算效率，提高系統的整體處理能力。
第二種極端情況，如果我們的操作純粹是IO或者數據庫，那么響應時間的主要限制就變為等待外部資源，此時maxThreads應該盡量設的大，這樣才能提高同時處理請求的個數，從而提高系統整體的處理能力。此情況下因為tomcat同時處理的請求量會比較大，所以需要關注一下tomcat的虛擬機內存設置和linux的open file限制。
我在測試時遇到一個問題，maxThreads我設置的比較大比如3000，當服務的線程數大到一定程度時，一般是2000出頭，單次請求的響應時間就會急劇的增加，
百思不得其解這是為什么，四處尋求答案無果，最后我總結的原因可能是cpu在線程切換時消耗的時間隨着線程數量的增加越來越大，
cpu把大多數時間都用來在這2000多個線程直接切換上了，當然cpu就沒有時間來處理我們的程序了。
以前一直簡單的認為多線程=高效率。。其實多線程本身並不能提高cpu效率，線程過多反而會降低cpu效率。
當cpu核心數<線程數時，cpu就需要在多個線程直接來回切換，以保證每個線程都會獲得cpu時間，即通常我們說的並發執行。
所以maxThreads的配置絕對不是越大越好。
現實應用中，我們的操作都會包含以上兩種類型（計算、等待），所以maxThreads的配置並沒有一個最優值，一定要根據具體情況來配置。
最好的做法是：在不斷測試的基礎上，不斷調整、優化，才能得到最合理的配置。
acceptCount的配置，我一般是設置的跟maxThreads一樣大，這個值應該是主要根據應用的訪問峰值與平均值來權衡配置的。
如果設的較小，可以保證接受的請求較快相應，但是超出的請求可能就直接被拒絕
如果設的較大，可能就會出現大量的請求超時的情況，因為我們系統的處理能力是一定的。
maxThreads 配置要結合 JVM -Xmx 參數調整，也就是要考慮內存開銷。