摘要:在利用收集了兩次的相關(guān)數(shù)據(jù),發(fā)現(xiàn)這和的存在關(guān)系,圖表如下在第一次的前期,動作比較多,此時的吞吐量一直維持在比較低的水平。第二次幾乎沒有的動作,此時的吞吐量一直維持在比較高的水平。
本文是在Tomcat調(diào)優(yōu)過程中得到的心得(會持續(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
JIT的介入Tomcat server.xml都保持默認值。
在不重啟Tomcat的情況下,兩次benchmark得到的throughput數(shù)據(jù)相差較大:
第一次:9000/s
第二次:17000/s
這也就說明,在Tomcat存在warmup機制,性能表現(xiàn)在warmup之后會更好。
在利用jvisualvm收集了兩次benchmark的相關(guān)數(shù)據(jù),發(fā)現(xiàn)這和JDK的compilerThread存在關(guān)系,圖表如下:
在第一次benchmark的前期,compilerThread動作比較多,此時NIO的吞吐量一直維持在比較低的水平。在第一次benchmark后期,compilerThread降下來了,NIO的吞吐量就上去了。
第二次benchmark幾乎沒有compilerThread的動作,此時NIO的吞吐量一直維持在比較高的水平。
在經(jīng)過一番調(diào)查之后,發(fā)現(xiàn)這是由于JIT對代碼做優(yōu)化,JIT會將頻繁執(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
maxThreads根據(jù)Tomcat文檔的說法,此參數(shù)決定了同時最多能夠處理多少請求,默認值是200。而我們的Jmeter腳本是300并發(fā),顯然不夠,所以調(diào)整server.xml追加Connector參數(shù):
maxThreads="500" minSpareThreads="500"
這么配置是提高Tomcat處理線程數(shù),maxThreads和minSpareThreads設(shè)置為一樣是讓Tomcat在啟動時就創(chuàng)建1000線程,這個和把JVM參數(shù)-Xms、-Xmx設(shè)置為一樣是一個道理。
在不重啟Tomcat的情況下,兩次benchmark得到的throughput數(shù)據(jù):
第一次:12000/s
第二次:17000/s
這說明在沒有warmup的情況下,maxThreads的提升能夠提升Tomcat的性能表現(xiàn)。
關(guān)于maxThreads應(yīng)該設(shè)置多少為合適可以見SO的這個回答:
How to determine the best number of threads in Tomcat?
processorCacheprocessorCache控制Tomcat內(nèi)部RequestProcessor的緩存池大小,當并發(fā)量大于此值時,Tomcat會創(chuàng)建新的RequestProcessor實例,如果并發(fā)量持續(xù)大于此值,則會持續(xù)創(chuàng)建RequestProcessor實例。
在這次壓力測試過程中,發(fā)現(xiàn)如果processorCache=100時,Tomcat只會保留100個RequestProcessor,并且會不斷創(chuàng)建其實例。見下圖:
如果processorCache=400,則Tomcat會保留300個RequestProcessor,并且不會創(chuàng)建新的實例,主要是因為Jmeter的線程數(shù)為300,也就是說同時最多只會有300個connection,每個connection對應(yīng)一個RequestProcessor。
從測試結(jié)果上看,processorCache=100時似乎并不影響測試結(jié)果。
gzip壓縮和gzip壓縮相關(guān)的參數(shù)有:compression、compressibleMimeType 、compressionMinSize ,Tomcat默認是關(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
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/70008.html
摘要:很多人做開發(fā),年后,都會感覺自己遇到瓶頸。公司的工作節(jié)奏又比較快,難有機會學習架構(gòu)原理,也沒人教,所以這個時候,學習架構(gòu)原理,擴展思維,對自己以后職業(yè)生涯尤為重要。 很多人做Java開發(fā)4,5年后,都會感覺自己遇到瓶頸。什么都會又什么都不會,如何改變困境,為什么很多人寫了7,8年還是一個碼農(nóng),工作中太多被動是因為不懂底層原理。公司的工作節(jié)奏又比較快,難有機會學習架構(gòu)原理,也沒人教,所以...
摘要:用于生成虛擬機當前時刻的線程快照。線程快照就是當前虛擬機內(nèi)每一條線程正在執(zhí)行的方法堆棧的集合,生成線程快照的主要目的就是定位線程出現(xiàn)長時間停頓的原因,如線程死鎖死循環(huán)請求外部資源導致的長時間等待等都是導致線程長時間停頓的常見原因。 在JDK的命令行中,一般開發(fā)人員最耳熟能詳?shù)目隙ň褪莏ava,javac,javap等常用命令,不過在jdk/bin下還有許多其他的命令行工具,它們被用來監(jiān)...
閱讀 1776·2021-10-27 14:15
閱讀 3835·2021-10-08 10:12
閱讀 1168·2021-09-22 15:55
閱讀 3230·2021-09-22 15:17
閱讀 834·2021-09-02 15:40
閱讀 1748·2019-08-29 18:33
閱讀 1099·2019-08-29 15:22
閱讀 2355·2019-08-29 11:08