摘要：在利用收集了兩次的相關(guān)數(shù)據(jù)，發(fā)現(xiàn)這和的存在關(guān)系，圖表如下在第一次的前期，動(dòng)作比較多，此時(shí)的吞吐量一直維持在比較低的水平。第二次幾乎沒有的動(dòng)作，此時(shí)的吞吐量一直維持在比較高的水平。

本文是在Tomcat調(diào)優(yōu)過程中得到的心得（會(huì)持續(xù)更新），相關(guān)環(huán)境：

java version "1.8.0_131"

Tomcat 8.5.14

Jmeter 3.1

Jmeter參數(shù)：

300線程

1000循環(huán)

URL：http://localhost:8080/

Tomcat server.xml參數(shù)：

protocol="org.apache.coyote.http11.Http11Nio2Protocol"

acceptCount="5000"

maxConnections="20000"

Tomcat JVM參數(shù)：-server -Xms4g -Xmx4g

Tomcat server.xml都保持默認(rèn)值。

在不重啟Tomcat的情況下，兩次benchmark得到的throughput數(shù)據(jù)相差較大：

第一次：9000/s

第二次：17000/s

這也就說明，在Tomcat存在warmup機(jī)制，性能表現(xiàn)在warmup之后會(huì)更好。

在利用jvisualvm收集了兩次benchmark的相關(guān)數(shù)據(jù)，發(fā)現(xiàn)這和JDK的compilerThread存在關(guān)系，圖表如下：

在第一次benchmark的前期，compilerThread動(dòng)作比較多，此時(shí)NIO的吞吐量一直維持在比較低的水平。在第一次benchmark后期，compilerThread降下來了，NIO的吞吐量就上去了。

第二次benchmark幾乎沒有compilerThread的動(dòng)作，此時(shí)NIO的吞吐量一直維持在比較高的水平。

在經(jīng)過一番調(diào)查之后，發(fā)現(xiàn)這是由于JIT對代碼做優(yōu)化，JIT會(huì)將頻繁執(zhí)行的代碼的bytecode編譯成native code，從而加快執(zhí)行速度。參考文章如下：

Java on Steroids: 5 Super Useful JIT Optimization Techniques

A close look at Java’s JIT: Don’t Waste Your Time on Local Optimizations

The Java JIT Compiler is Darn Good at Optimization

根據(jù)Tomcat文檔的說法，此參數(shù)決定了同時(shí)最多能夠處理多少請求，默認(rèn)值是200。而我們的Jmeter腳本是300并發(fā)，顯然不夠，所以調(diào)整server.xml追加Connector參數(shù)：

maxThreads="500"
minSpareThreads="500"

這么配置是提高Tomcat處理線程數(shù)，maxThreads和minSpareThreads設(shè)置為一樣是讓Tomcat在啟動(dòng)時(shí)就創(chuàng)建1000線程，這個(gè)和把JVM參數(shù)-Xms、-Xmx設(shè)置為一樣是一個(gè)道理。

在不重啟Tomcat的情況下，兩次benchmark得到的throughput數(shù)據(jù)：

第一次：12000/s

第二次：17000/s

這說明在沒有warmup的情況下，maxThreads的提升能夠提升Tomcat的性能表現(xiàn)。

關(guān)于maxThreads應(yīng)該設(shè)置多少為合適可以見SO的這個(gè)回答：

How to determine the best number of threads in Tomcat?

processorCache控制Tomcat內(nèi)部RequestProcessor的緩存池大小，當(dāng)并發(fā)量大于此值時(shí)，Tomcat會(huì)創(chuàng)建新的RequestProcessor實(shí)例，如果并發(fā)量持續(xù)大于此值，則會(huì)持續(xù)創(chuàng)建RequestProcessor實(shí)例。

在這次壓力測試過程中，發(fā)現(xiàn)如果processorCache=100時(shí)，Tomcat只會(huì)保留100個(gè)RequestProcessor，并且會(huì)不斷創(chuàng)建其實(shí)例。見下圖：

如果processorCache=400，則Tomcat會(huì)保留300個(gè)RequestProcessor，并且不會(huì)創(chuàng)建新的實(shí)例，主要是因?yàn)镴meter的線程數(shù)為300，也就是說同時(shí)最多只會(huì)有300個(gè)connection，每個(gè)connection對應(yīng)一個(gè)RequestProcessor。

從測試結(jié)果上看，processorCache=100時(shí)似乎并不影響測試結(jié)果。

和gzip壓縮相關(guān)的參數(shù)有：compression、compressibleMimeType 、compressionMinSize ，Tomcat默認(rèn)是關(guān)閉gzip壓縮的，gzip壓縮能夠顯著降低帶寬。

以下是在warmup之后的benchmark結(jié)果，開啟gzip能得到17%的性能提升：

compression="on"：17073.6/s

compression="off"：14548.3/s

但是在benchmark多次之后，發(fā)現(xiàn)開啟和不開啟的結(jié)果相近。

So You Want High Performance

Tuning Tomcat For A High Throughput, Fail Fast System