tomcat的acceptCount、maxThreads、connectionTimeout參數調整

acceptCount值調整(默認100)

acceptCount的經驗值的範圍爲50-300，當tomcat的處理能力不夠快的時候，能夠調整該值，比較有用。

• 當系統的併發量比較大的時候，關閉keep alive，而後適當調整該值

• 當鏈接創建以後，常常得不到worker線程處理時，能夠適當下降該值，開啓keep alive

當該值設置爲比較大的時候，請求的突增，會很快填滿accept隊列(完成三次握手創建鏈接，等待工做線程處理響應，若是一直沒獲得service，則client得不到響應，出現read timeout，最糟糕的狀況是鏈接在accept隊列等待了好久，等到能獲得worker線程服務的時候，已經超時了，這樣其實浪費了不少鏈接)，讓woker線程很是繁忙，當超過系統的承受能力的時候，請求不斷堆積，而後致使工做線程cpu餓死(starvation)。所以須要系統進行自我保護，當超出負載能力的時候，迅速fail fast，返回503。

所以要合理評估系統高峯的時候，worker線程池的大小。假設server平均每一個請求耗時5ms，那麼1個線程每秒rps能夠有200，假設有4核cpu，那麼每秒最大能夠有800rps。如今假若有4個請求同時進來，那麼4個線程將繁忙起來，也就是接下來的5ms中，這些線程時繁忙的。那麼對於這個4核cpu的系統來講，最大的rps就是800.

當acceptCount的值設置的過小的時候，當請求量大的時候，操做系統沒法給tomcat創建更多的鏈接(沒法完成三次握手)，client端出現不少connect timeout，而這些被拒絕掉的請求多是在worker線程的處理能力以內的。

當開啓http keep alive的時候，client端可能沒有那麼及時地關閉鏈接，那麼server端的worker線程會一直被這些實際上可能不活躍的鏈接給佔用了，致使worker線程沒能重複利用起來。可是關閉http keep alive的時候，頻繁的地進行tcp鏈接和端口，這樣會形成不少TIME_WAIT的socket，給服務端增長壓力。

maxThreads值調整(默認200)

• 經驗值範圍爲200-800，能夠從400設置起再進行調優

• 表明最大的併發請求數

• 當cpu利用率高的時候，不宜增長線程的個數，能夠調小該值

• 當cpu利用率不高，大部分是io阻塞類的操做時，能夠適當增長該值

connectionTimeout(默認值爲60000毫秒)

• 經驗值爲2000-60000，默認的60秒對於一個web server可能過高了，能夠設置爲3000

• 實際上指的是SO_TIMEOUT參數的值

• 表明在阻塞讀寫時，兩個tcp包到來的最大間隔時間

• 當client比較慢的時候，能夠增大該值

• 當須要快速超時時，能夠下降該值

doc

• Tuning Tomcat For A High Throughput, Fail Fast System

• PerformanceTuningApacheTomcat-Part2