Tomcat?7 在我們日常開發(fā)、測試、生產環(huán)境都會使用到，但對于大部分開發(fā)人員來說，對其性能還是沒有多大了解。本文就對它做一次性能測試，對比優(yōu)化前后的性能區(qū)別。
一、運行環(huán)境
CPU ：? Intel(R)?Pentium(R)?P6200@2.13GHz?? ；
內存： 4G ，裝的是 32 位 win7 ，只認出 3G ，沒有花時間去整 ramdisk 之類的東西；
操作系統(tǒng)： win7?32 位；
JDK ： 1.7.0_55
Tomcat ： 7.0.53
大家不要笑，公司電腦，就給配這樣的，慢的要死，悲劇！
下面所有測試都是基于 1000 個請求做的，且都是訪問 Tomcat 默認的 ROOT 首頁
二、未調優(yōu)前
并發(fā)用戶數從 10-1000 挨個測試，測試結果如下：
?
從上面的測試結果來看，除去 200 用戶并發(fā)的時候（這時候可能在做 GC ），吞吐率和請求處理時間都比較穩(wěn)定，但請求等待時間到后面就颼颼的往上漲了。經觀察， CPU 負載均在 80% 以下。
?
三、優(yōu)化后
優(yōu)化主要是對 Tomcat 做的，主要有兩方面：
1 、 在 bin/catalina.bat 文件中加入下面參數，對 JVM 進行優(yōu)化，至于這一大駝參數的作用及說明，大家到網上找找，應該有很多的，如： http://www.mzone.cc/article/321.html
|
01 |
set?JAVA_OPTS= |
|
|
02 |
-server? |
|
?
|
03 |
-Xms1000M? |
|
|
04 |
-Xmx1000M???#-Xms與-Xmx設成一樣的值，避免JVM因為頻繁的GC導致性能大起大落 |
|
?
|
05 |
-Xss512k? |
|
|
06 |
-XX:+AggressiveOpts? |
|
?
|
07 |
-XX:+UseBiasedLocking? |
|
|
08 |
-XX:PermSize=64M? |
|
?
|
09 |
-XX:MaxPermSize=300M? |
|
|
10 |
-XX:+DisableExplicitGC? |
|
?
|
11 |
-XX:MaxTenuringThreshold=31? |
|
|
12 |
-XX:+UseConcMarkSweepGC? |
|
?
|
13 |
-XX:+UseParNewGC?? |
|
|
14 |
-XX:+CMSParallelRemarkEnabled? |
|
?
|
15 |
-XX:+UseCMSCompactAtFullCollection? |
|
|
16 |
-XX:LargePageSizeInBytes=128m?? |
|
?
|
17 |
-XX:+UseFastAccessorMethods? |
|
|
18 |
-XX:+UseCMSInitiatingOccupancyOnly? |
|
?
|
19 |
-Djava.awt.headless=true |
上述這樣的配置，基本上可以達到：
- 系統(tǒng)響應時間增快
- JVM回收速度增快同時又不影響系統(tǒng)的響應率
- JVM內存最大化利用
- 線程阻塞情況最小化
?
2 、 Tomcat 連接參數的優(yōu)化，主要是針對吞吐量做優(yōu)化：
修改 conf/server.xml 文件，把原來
|
1 |
<Connector?port="8080"?protocol="HTTP/1.1"?/> |
改成下面的內容
|
01 |
??<Connector?port="8080"?protocol="HTTP/1.1" |
|
|
02 |
???????????URIEncoding="UTF-8"?? |
|
?
|
03 |
???????????minSpareThreads="25"? |
|
|
04 |
???????????maxSpareThreads="75" |
|
?
|
05 |
???????????enableLookups="false"? |
|
|
06 |
???????????disableUploadTimeout="true"? |
|
?
|
07 |
???????????connectionTimeout="20000" |
|
|
08 |
???????????acceptCount="300"??? |
|
?
|
09 |
???????????maxThreads="300"? |
|
|
10 |
???????????maxProcessors="1000"? |
|
?
|
11 |
???????????minProcessors="5" |
|
|
12 |
???????????useURIValidationHack="false" |
|
?
|
13 |
???????????compression="on"? |
|
|
14 |
???????????compressionMinSize="2048" |
|
?
|
15 |
???????????compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" |
||
|
16 |
???????????redirectPort="8443"/> |
||
然后我們再來看看
10-1000
個并發(fā)用戶發(fā)起
1000
個請求時所表現的性能是怎么的。
大家可以看到，經過優(yōu)化后，吞吐率已經能達到平均 1800-1900 左右，而處理時間基本能穩(wěn)定在 0.6ms ，而等待時間最高不到 600ms 。
四、總結
通過兩個結果對比可以看出，吞吐率及服務器處理時間有很大的改觀，當然在我這破機器上也就這樣一個效果了，再優(yōu)化估計也不會 “ 飛 ” 起來，有興趣的朋友可以找臺牛 B 點的機器自己試試。試完了希望告訴我結果，讓我也高興一下。
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
