tomcat相關優化

1、tomcat內存優化 (調優內存是最直接的方式)

默認情況下tomcat的相關內存配置較低，這對於一些大型項目顯然是不夠用的，這些項目運行就已經耗費了大部分內存空間，何況大規模訪問的情況。即使只有一個頁面的超小項目，在並發達到一定程度後也會拋出以下類似異常：

嚴重: Exception invoking periodic operation: java.lang.OutOfMemoryError: Java heap space

嚴重: Error processing request java.lang.OutOfMemoryError: GC overhead limit exceeded

說明tomcat已經無力支持訪問處理，內部GC也已經“無能無力”。所以一般情況下我們需要重新配置tomcat的相關內存大小，Linux下修改TOMCAT_HOME/bin/catalina.sh，在其中加入，可以放在CLASSPATH=下面

JAVA_OPTS="-server -XX:PermSize=512M -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m"

windows下修改TOMCAT_HOME/bin/catalina.bat，在其中加入，可以放在set CLASSPATH=下面

set JAVA_OPTS=-server -XX:PermSize=512M -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m

參數說明：

-server：啓用 JDK的 server 版本；

-Xms：Java虛擬機初始化時堆的最小內存，一般與 Xmx配置爲相同值，這樣的好處是GC不必再爲擴展內存空間而消耗性能；

-Xmx：Java虛擬機可使用堆的最大內存；

-XX:PermSize：Java虛擬機永久代大小；

-XX:MaxPermSize：Java虛擬機永久代大小最大值；

除了這些參數外您還可以根據具體需要配置其他參數，參數的配置可以參考JVM參數的配置

2、內存優化後驗證方法

設置成功後我們可以利用JDK自帶的工具進行驗證，這些工具都在JAVA_HOME/bin目錄下：

jps：用來顯示本地的java進程，以及進程號，進程啓動的路徑等。

jmap：觀察運行中的JVM 物理內存的佔用情況，包括Heap size , Perm size等。

進入命令行模式後，進入JAVA_HOME/bin目錄下，然後輸入./jps命令可查看我們啓動的tomcat的Bootstrap進程號。然後我們利用 jmap工具查看其內存相關配置

[root@localhost bin]# jps

6515 Bootstrap

6531 Jps

[root@localhost bin]# jmap -heap 6515

Attaching to process ID 6515, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.171-b11

using thread-local object allocation.

Mark Sweep Compact GC

Heap Configuration:

MinHeapFreeRatio = 40

MaxHeapFreeRatio = 70

MaxHeapSize = 2147483648 (2048.0MB)

NewSize = 715784192 (682.625MB)

MaxNewSize = 715784192 (682.625MB)

OldSize = 1431699456 (1365.375MB)

NewRatio = 2

SurvivorRatio = 8

MetaspaceSize = 21807104 (20.796875MB)

CompressedClassSpaceSize = 1073741824 (1024.0MB)

MaxMetaspaceSize = 17592186044415 MB

G1HeapRegionSize = 0 (0.0MB)

Heap Usage:

New Generation (Eden + 1 Survivor Space):

capacity = 644218880 (614.375MB)

used = 114531328 (109.2255859375MB)

free = 529687552 (505.1494140625MB)

17.77832527975585% used

Eden Space:

capacity = 572653568 (546.125MB)

used = 114531328 (109.2255859375MB)

free = 458122240 (436.8994140625MB)

20.00010728999771% used

From Space:

capacity = 71565312 (68.25MB)

used = 0 (0.0MB)

free = 71565312 (68.25MB)

0.0% used

To Space:

capacity = 71565312 (68.25MB)

used = 0 (0.0MB)

free = 71565312 (68.25MB)

0.0% used

tenured generation:

capacity = 1431699456 (1365.375MB)

used = 0 (0.0MB)

free = 1431699456 (1365.375MB)

0.0% used

9746 interned Strings occupying 1537792 bytes.

3、tomcat 配置優化

3.1、Connector 優化

Connector是連接器，負責接收客戶的請求，以及向客戶端回送響應的消息。所以 Connector的優化是重要部分。默認情況下 tomcat只支持200線程訪問，超過這個數量的連接將被等待甚至超時放棄，所以我們需要提高這方面的處理能力。

修改這部分配置需要修改TOMCAT_HOME/conf/server.xml，打開server.xml找到Connector 標籤項，默認配置如下：

<Connector port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443" />

其中port代表服務接口；protocol代表協議類型；connectionTimeout代表連接超時時間，單位爲毫秒；redirectPort代表安全通信（https）轉發端口，一般配置成443。

可以看到除了這幾個基本配置外並無特殊功能，所以我們需要對 Connector 進行擴展。其中Connector 支持參數屬性可以參考tomcat官方網站（https://tomcat.apache.org/tomcat-8.0-doc/config/http.html），非常多，所以本文就只介紹些常用的。我們將 Connector 配置修改爲如下：

<Connector port="8080"

protocol="HTTP/1.1"

maxThreads="1000"

minSpareThreads="100"

acceptCount="1000"

maxConnections="1000"

connectionTimeout="20000"

maxHttpHeaderSize="8192"

tcpNoDelay="true"

compression="on"

compressionMinSize="2048"

disableUploadTimeout="true"

redirectPort="8443"

enableLookups="false"

URIEncoding="UTF-8" />

1、port：代表tomcat監聽端口，也就是網站的訪問端口，默認爲8080，可以根據需要改成其他。

2、protocol：協議類型，可選類型有四種，分別爲BIO（阻塞型IO），NIO，NIO2和APR。

（1）BIO：BIO(Blocking I/O)，顧名思義，即阻塞式I/O操作，表示tomcat使用的是傳統的Java I/O操作(即java.io包及其子包)。tomcat在默認情況下，是以bio模式運行的。遺憾的是，就一般而言，bio模式是三種運行模式中性能最低的一種。BIO配置採用默認即可。

（2）NIO：NIO(New I/O)，是Java SE 1.4及後續版本提供的一種新的I/O操作方式(即java.nio包及其子包)。Java nio是一個基於緩衝區、並能提供非阻塞I/O操作的java API，因此nio也被看成是non-blocking I/O的縮寫。它擁有比傳統I/O操作(bio)更好的併發運行性能。要讓tomcat以nio模式來運行也比較簡單，我們只需要protocol類型修改爲即可。

//NIO

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

//NIO2

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

（3）APR：APR(Apache Portable Runtime/Apache可移植運行時)，是Apache HTTP服務器的支持庫。你可以簡單地理解爲:tomcat將以JNI的形式調用 Apache HTTP服務器的核心動態鏈接庫來處理文件讀取或網絡傳輸操作，從而大大地提高 tomcat對靜態文件的處理性能。與配置 NIO運行模式一樣，也需要將對應的 Connector節點的 protocol屬性值改爲：

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

3、maxThreads：由該連接器創建的處理請求線程的最大數目，也就是可以處理的同時請求的最大數目。如果未配置默認值爲200。如果一個執行器與此連接器關聯，則忽略此屬性，因爲該屬性將被忽略，所以該連接器將使用執行器而不是一個內部線程池來執行任務。

maxThreads是一個重要的配置屬性，maxThreads配置的合理直接影響了tomcat的相關性能，所以這裏我們重點討論下。maxThreads並不是配置的越大越好，事實上你即使配置成999999也是沒有用的，因爲這個最大值是受操作系統及相關硬件所制約的，並且最大值並不一定是最優值，所以我們追尋的應該是最優值而不是最大值。

QPS（Query Per Second）：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。我們常常使用 QPS值來衡量一個服務器的性能。

QPS = 併發數 / 平均響應時間或者併發數 = QPS * 平均響應時間

一個系統吞吐量通常由QPS、併發數兩個因素決定，每套系統的這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。所謂吞吐量這裏可以理解爲每秒能處理請求的次數。所以選擇一個合理的 maxThreads值，其實並不是那麼容易的事。因爲過多的線程只會造成，更多的內存開銷，更多的CPU開銷，但是對提升QPS確毫無幫助；找到最佳線程數後通過簡單的設置，可以讓web系統更加穩定，得到最高，最穩定的QPS輸出。

我們可以通過以下幾種方式來獲取 maxThreads的最佳值：

（1）通過線上系統不斷使用和用戶的不斷增長來進行性能測試，觀察QPS，響應時間，這種方式會在爆發式增長時系統崩潰，如雙12等。

（2）根據公式計算，服務器端最佳線程數量=((線程等待時間+線程cpu時間)/線程cpu時間) * cpu數量，這種方式有時會被誤導，因爲某些系統處理環節可能會耗時比較長，從而影響公式的結果。

（3）單、多用戶壓力測試，查看CPU的消耗，然後直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳線程數量，這種方式理想場景比較適用，實際情況會比這個複雜的多。

（4）根據系統的自身情況調整，如硬件限制，系統限制，程序處理能力限制等。

（5）定期修改爲不同的 maxThreads值，看服務器響應結果及用戶反應。

QPS和線程數的關係

（1）在最佳線程數量之前，QPS和線程是互相遞增的關係，線程數量到了最佳線程之後，QPS持平，不在上升，甚至略有下降，同時相應時間持續上升。

（2）同一個系統而言，支持的線程數越多（最佳線程數越多而不是配置的線程數越多），QPS越高。

QPS和響應時間的關係

（1）對於一般的web系統，響應時間一般有CPU執行時間+IO等待時間組成。

（2）CPU的執行時間減少，對QPS有實質的提升，IO時間的減少，對QPS提升不明顯。如果要想明顯提升QPS，優化系統的時候要着重優化CPU消耗大戶。所以想要找出 maxThreads的最優值可並不容易，沒有最好只有更好，更好的值只能通過時間來顯現，如果你不想考慮那麼多，一般情況下設置成1000即可。

4、minSpareThreads：線程的最小運行數目，這些始終保持運行。如果未指定，默認值爲10。

5、acceptCount：當所有可能的請求處理線程都在使用時傳入連接請求的最大隊列長度。如果未指定，默認值爲100。一般是設置的跟 maxThreads一樣或一半，此值設置的過大會導致排隊的請求超時而未被處理。所以這個值應該是主要根據應用的訪問峯值與平均值來權衡配置。

6、maxConnections：在任何給定的時間內，服務器將接受和處理的最大連接數。當這個數字已經達到時，服務器將接受但不處理，等待進一步連接。NIO與NIO2的默認值爲10000，APR默認值爲8192。

7、connectionTimeout：當請求已經被接受，但未被處理，也就是等待中的超時時間。單位爲毫秒，默認值爲60000。通常情況下設置爲30000。

8、maxHttpHeaderSize：請求和響應的HTTP頭的最大大小，以字節爲單位指定。如果沒有指定，這個屬性被設置爲8192（8 KB）。

9、tcpNoDelay：如果爲true，服務器socket會設置TCP_NO_DELAY選項，在大多數情況下可以提高性能。缺省情況下設爲true。

10、compression：是否啓用gzip壓縮，默認爲關閉狀態。這個參數的可接受值爲“off”（不使用壓縮），“on”（壓縮文本數據），“force”（在所有的情況下強制壓縮）。

11、compressionMinSize：如果compression="on"，則啓用此項。被壓縮前數據的最小值，也就是超過這個值後才被壓縮。如果沒有指定，這個屬性默認爲“2048”（2K），單位爲byte。

12、disableUploadTimeout：這個標誌允許servlet Container在一個servlet執行的時候，使用一個不同的，更長的連接超時。最終的結果是給servlet更長的時間以便完成其執行，或者在數據上載的時候更長的超時時間。如果沒有指定，設爲false。

13、enableLookups：關閉DNS反向查詢。

14、URIEncoding：URL編碼字符集。

Connector 還有很多其他參數，可以參考tomcat官網，這裏只介紹與性能相關的部分。

3.2、tomcat的IO優化BIO、NIO、APR

通過配置 protocol的類型可以使用不同的 Connector處理請求。

//BIO

protocol="HTTP/1.1"

//NIO

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

//NIO2

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

//APR

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

以下是幾種類型 Connector的參數對比：

並不是說 BIO的性能就一定不如 NIO，這幾種類型 Connector之間並沒有明顯的性能區別，它們之間實現流程和原理不同，所以它們的選擇是需要根據應用的類型來決定的。

BIO（同步阻塞IO）更適合處理簡單流程，如程序處理較快可以立即返回結果。服務器實現模式爲一個連接一個線程，當然可以通過線程池機制改善。BIO方式適用於連接數目比較小且固定的架構，這種方式對服務器資源要求比較高，併發侷限於應用中，JDK1.4以前的唯一選擇，但程序直觀簡單易理解.

NIO（分爲同步非阻塞IO，異步阻塞IO）更適合後臺需要耗時完成請求的操作，如程序接到了請求後需要比較耗時的處理這已請求，所以無法立即返回結果，這樣如果採用BIO就會佔用一個連接，而使用NIO後就可以將此連接轉讓給其他請求，直至程序處理完成返回爲止。與BIO最大的區別，可以複用同一個線程處理多個connection(多路複用)。NIO方式適用於連接數目多且連接比較短（輕操作）的架構，比如聊天服務器，併發侷限於應用中，編程比較複雜，JDK1.4開始支持.

Java NIO2（又叫AIO異步非阻塞IO），主要與NIO的區別主要是操作系統的底層區別，可以做個比喻:比作快遞，NIO就是網購後要自己到官網查下快遞是否已經到了(可能是多次)，然後自己去取快遞；AIO就是快遞員送貨上門了(不用關注快遞進度)。AIO方式使用於連接數目多且連接比較長（重操作）的架構，比如相冊服務器，充分調用OS參與併發操作，編程比較複雜，JDK7開始支持.

APR可以大大提升tomcat對靜態文件的處理性能，同時如果你使用了HTTPS方式傳輸的話，也可以提升SSL的處理性能。APR是從操作系統級別來解決異步的IO問題,大幅度的提高性能. (http://apr.apache.org/)。APR(Apache Portable Runtime)是一個高可移植庫,它是Apache HTTP Server 2.x的核心.能更好地和其它本地web技術集成，總體上讓Java更有效率作爲一個高性能web服務器平臺而不是簡單作爲後臺容器。在產品環境中，特別是直接使用tomcat做WEB服務器的時候，應該使用tomcat Native來提高其性能.如果不配APR，基本上300個線程狠快就會用滿，以後的請求就只好等待.但是配上APR之後，併發的線程數量明顯下降，從原來的300可能會馬上下降到只有幾十，新的請求會毫無阻塞的進來.

在局域網環境測，就算是400個併發，也是一瞬間就處理/傳輸完畢，但是在真實的Internet環境下，頁面處理時間只佔0.1%都不到，絕大部分時間都用來頁面傳輸.如果不用APR，一個線程同一時間只能處理一個用戶，勢必會造成阻塞。所以生產環境下用apr是非常必要的.

3.3、線程池

Executor代表了一個線程池，可以在tomcat組件之間共享。使用線程池的好處在於減少了創建銷燬線程的相關消耗，而且可以提高線程的使用效率。要想使用線程池，首先需要在 Service標籤中配置 Executor，如下：

<Executor name="tomcatThreadPool"

namePrefix="catalina-exec-"

maxThreads="1000"

minSpareThreads="100"

maxIdleTime="60000"

maxQueueSize="Integer.MAX_VALUE"

prestartminSpareThreads="false"

threadPriority="5"

className="org.apache.catalina.core.StandardThreadExecutor"/>

....

參數說明：

name：線程池名稱，用於 Connector中指定。

namePrefix：所創建的每個線程的名稱前綴，一個單獨的線程名稱爲 namePrefix+threadNumber。

maxThreads：池中最大線程數。

minSpareThreads：活躍線程數，也就是核心池線程數，這些線程不會被銷燬，會一直存在。

maxIdleTime：線程空閒時間，超過該時間後，空閒線程會被銷燬，默認值爲6000（1分鐘），單位毫秒。

maxQueueSize：在被執行前最大線程排隊數目，默認爲Int的最大值，也就是廣義的無限。除非特殊情況，這個值不需要更改，否則會有請求不會被處理的情況發生。

prestartminSpareThreads：啓動線程池時是否啓動 minSpareThreads部分線程。默認值爲false，即不啓動。

threadPriority：線程池中線程優先級，默認值爲5，值從1到10。

className：線程池實現類，未指定情況下，默認實現類爲org.apache.catalina.core.StandardThreadExecutor。如果想使用自定義線程池首先需要實現 org.apache.catalina.Executor接口。

線程池配置完成後需要在 Connector中指定：

<Connector executor="tomcatThreadPool"

...

3.4、Listener

另一個影響tomcat 性能的因素是內存泄露。Server標籤中可以配置多個Listener，其中 JreMemoryLeakPreventionListener是用來預防JRE內存泄漏。此Listener只需在Server標籤中配置即可，默認情況下無需配置，已經添加在 Server中。

4、組件優化

4.1、APR介紹及安裝說明

4.1.1、APR介紹

APR(Apache Portable Runtime)是一個高可移植庫，它是Apache HTTP Server 2.x的核心。APR有很多用途，包括訪問高級 IO功能(例如sendfile,epoll和OpenSSL)，OS級別功能(隨機數生成，系統狀態等等)，本地進程管理(共享內存，NT管道和UNIX sockets)。這些功能可以使tomcat作爲一個通常的前臺WEB服務器，能更好地和其它本地web技術集成，總體上讓Java更有效率作爲一個高性能web服務器平臺而不是簡單作爲後臺容器。

APR的目的如其名稱一樣，主要爲上層的應用程序提供一個可以跨越多操作系統平臺使用的底層支持接口庫。在早期的Apache版本中，應用程序本身必須能夠處理各種具體操作系統平臺的細節，並針對不同的平臺調用不同的處理函數。隨着Apache的進一步開發，Apache組織決定將這些通用的函數獨立出來並發展成爲一個新的項目。這樣，APR的開發就從Apache中獨立出來，Apache僅僅是使用APR而已。目前APR主要還是由Apache使用，不過由於APR的較好的移植性，因此一些需要進行移植的C程序也開始使用APR。

APR使得平臺細節的處理進行下移。對於應用程序而言，它們根本就不需要考慮具體的平臺，不管是Unix、linux還是Window，應用程序執行的接口基本都是統一一致的。因此對於APR而言，可移植性和統一的上層接口是其考慮的一個重點。而APR最早的目的並不是如此，它最早只是希望將Apache中用到的所有代碼合併爲一個通用的代碼庫，然而這不是一個正確的策略，因此後來APR改變了其目標。有的時候使用公共代碼並不是一件好事，比如如何將一個請求映射到線程或者進程是平臺相關的，因此僅僅一個公共的代碼庫並不能完成這種區分。APR的目標則是希望安全合併所有的能夠合併的代碼而不需要犧牲性能。

4.1.2、APR下載

APR沒有二進制包可以下載，所以只能下載源代碼版，下載後需要構建，需要下載的文件有：apr-1.5.2.tar.gz、apr-iconv-1.2.1.tar.gz、apr-util-1.5.4.tar.gz（Linux版爲例）這三個。APR的官網爲：http://apr.apache.org/

4.1.3、APR安裝

windows下構建源代碼比較麻煩，需要Visual Studio支持。

Linux下構建就相對簡單和熟悉了，只需要執行常規構建命令即可：

./configure --prefix=/usr/local/apr

make

make install

安裝成功後，APR會默認安裝在 /usr/local/apr目錄下，也可以指定安裝目錄。apr-iconv安裝時需要指定apr的安裝位置：

./configure --prefix=/usr/local/apr-iconv --with-apr=/usr/local/apr

make

make install

apr-util安裝時需要指定apr的安裝位置：

./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr --with-apr-iconv=/usr/local/apr-iconv/bin/apriconv

make

make install

安裝完成後其實是無法直接使用APR的，想使用APR還需要安裝tomcat Native，否則tomcat啓動時會報以下錯誤：

16-May-2016 02:52:42.992 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/apr/lib:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

4.2、安裝tomcat Native

tomcat Native是 tomcat可選組件，它可以讓 tomcat使用 Apache 的 APR包來處理包括文件和網絡IO操作，從而提升性能及兼容性。

4.2.1、下載tomcat Native

tomcat Native可以選擇Windows與Linux版本下載。

tomcat Native下載地址爲：http://tomcat.apache.org/download-native.cgi

Linux/Unix下安裝tomcat Native前需要安裝以下組件：

APR library（我們已安裝）

OpenSSL libraries

Java SE Development Kit (JDK)（也已安裝）

4.2.2、OpenSSL libraries安裝

yum -y install apr-devel openssl-devel

安裝成功後就可以安裝tomcat Native了，運行以下命令

4.2.3、安裝tomcat Native

./configure --with-apr=/usr/local/apr/bin/apr-1-config \

--with-java-home=/usr/java/jdk1.7.0_79 \

--with-ssl=yes \

--prefix=/usr/local/tomcat

注意，--prefix指向的是 tomcat目錄。

安裝時需要進入native目錄。安裝過程中還有可能產生依賴包版本不兼容的問題（一般爲openssl版本過低），這時需要卸載舊的依賴，並安裝最新版本。當安裝完成後出現以下類似輸出時，說明安裝已經成功。

----------------------------------------------------------------------

Libraries have been installed in:

/usr/local/tomcat/lib

If you ever happen to want to link against installed libraries

in a given directory, LIBDIR, you must either use libtool, and

specify the full pathname of the library, or use the `-LLIBDIR'

flag during linking and do at least one of the following:

- add LIBDIR to the `LD_LIBRARY_PATH' environment variable

during execution

- add LIBDIR to the `LD_RUN_PATH' environment variable

during linking

- use the `-Wl,-rpath -Wl,LIBDIR' linker flag

- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for

more information, such as the ld(1) and ld.so(8) manual pages.

Windows下安裝就異常簡單了，只需要把bin目錄下文件複製到tomcat/bin下即可，如果爲64位，則複製x64中文件下載地址。

4.3、APR使用

4.3.1、環境變量配置

使用前需要配置環境變量，打開配置文件後，添加以下內容：

vi /etc/profile

export LD_LIBRARY_PATH=/usr/local/apr/lib

source /etc/profile #退出保存，然後執行

4.3.2、修改tomcat配置文件

打開conf/server.xml文件，修改Connector 標誌的protocol屬性：

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

然後添加Listener：

保存配置文件後，啓動tomcat，從日誌中看到以下輸出時，說明全部功能都已配置成功：

16-May-2016 04:28:54.734 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache tomcat Native library 1.1.34 using APR version 1.5.2.

16-May-2016 04:28:54.734 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].

16-May-2016 04:28:54.739 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized (OpenSSL 1.0.2h 3 May 2016)

至此，APR與 Native都已安裝完成，可以使用，對於 APR與 Native還有很多知識要學習，但不是本文的重點，所以以後有機會還會深入學習。

5、性能測試

tomcat優化部分我們已經完成，接下來就需要比較一下優化前與優化後的性能對比。

5.1、Jmeter介紹及使用

Apache JMeter是Apache組織開發的基於Java的壓力測試工具。用於對軟件做壓力測試，它最初被設計用於Web應用測試，但後來擴展到其他測試領域。它可以用於測試靜態和動態資源，例如靜態文件、Java 小服務程序、CGI 腳本、Java 對象、數據庫、FTP 服務器，等等。JMeter 可以用於對服務器、網絡或對象模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體性能。另外，JMeter能夠對應用程序做功能/迴歸測試，通過創建帶有斷言的腳本來驗證你的程序返回了你期望的結果。爲了最大限度的靈活性，JMeter允許使用正則表達式創建斷言。

Apache jmeter 可以用於對靜態的和動態的資源（文件，Servlet，Perl腳本，java 對象，數據庫和查詢，FTP服務器等等）的性能進行測試。它可以用於對服務器、網絡或對象模擬繁重的負載來測試它們的強度或分析不同壓力類型下的整體性能。你可以使用它做性能的圖形分析或在大併發負載測試你的服務器/腳本/對象。

Jmeter官網：http://jmeter.apache.org/

5.1.1、JMeter的作用

（1）能夠對HTTP和FTP服務器進行壓力和性能測試，也可以對任何數據庫進行同樣的測試（通過JDBC），Jmeter支持以下服務器協議類型測試：

• Web - HTTP, HTTPS

• SOAP / REST

• FTP

• Database via JDBC

• LDAP

• Message-oriented middleware (MOM) via JMS

• Mail - SMTP(S), POP3(S) and IMAP(S)

• MongoDB (NoSQL)

• Native commands or shell scripts

• TCP

（2）完全的可移植性和100% 純java。

（3）完全 Swing 和輕量組件支持（預編譯的JAR使用 javax.swing.*)包。

（4）完全多線程框架允許通過多個線程併發取樣和通過單獨的線程組對不同的功能同時取樣。

（5）精心的GUI設計允許快速操作和更精確的計時。

（6）緩存和離線分析/回放測試結果。

5.1.2、JMeter下載地址特性

（1）可鏈接的取樣器允許無限制的測試能力。

（2）各種負載統計表和可鏈接的計時器可供選擇。

（3）數據分析和可視化插件提供了很好的可擴展性以及個性化。

（4）具有提供動態輸入到測試的功能（包括JavaScript）。

（5）支持腳本編程的取樣器（在1.9.2及以上版本支持BeanShell）。

在設計階段，JMeter能夠充當HTTP PROXY（代理）來記錄IE/NETSCAPE的HTTP請求，也可以記錄apache等WebServer的log文件來重現HTTP流量。當這些HTTP客戶端請求被記錄以後，測試運行時可以方便的設置重複次數和併發度（線程數）來產生巨大的流量。JMeter還提供可視化組件以及報表工具把量服務器在不同壓力下的性能展現出來。

相比其他HTTP測試工具,JMeter最主要的特點在於擴展性強。JMeter能夠自動掃描其lib/ext子目錄下.jar文件中的插件，並且將其裝載到內存，讓用戶通過不同的菜單調用。

5.1.3、Jmeter使用

使用Jmeter非常簡單，windows下進入bin目錄直接雙擊jmeter.bat文件即可，Linux下類似，需要運行jmeter.sh文件，Jmeter運行後顯示以下界面：

Jmeter使用起來比較簡單，附件是一個簡單的配置，直接導入即可使用。

5.1.4、測試條件

tomcat版本：8.0.33

測試項目：新創建一個web項目也不用實現任何代碼，只需要部署即可以使用，只有一個index.jsp文件。

JDK版本：jdk1.7.0.67

請求方式：POST

循環次數：100，1000

線程數：10,100,1000

總次數：總次數 = 線程數 * 循環次數

CPU：英特爾第二代酷睿 i5-2450M（雙核）

內存：8GB

附件時Jmeter的配置文件，可以直接導入使用。

5.1.5、測試結果

從部分結果來看優化過的tomcat會比默認性能及併發處理能力上有提高，但至於參數的配置需要結合硬件及操作系統來不斷調整，所以並不會有一個萬能的參數來使用，需要各位不斷的測試不斷更改。

以下是一個簡單的測試結果，循環100次，線程數分別爲10,100,1000：

各位估計已經發現了相同的應用下並不一定某種protocol就一定性能出色，因爲tomcat中的這個測試項目只有一個index.jsp頁面，在較少線程數訪問情況下BIO反應最快，而當線程數達到1000時NIO2性能最出色，而APR中規中矩，雖然這種測試的侷限性很大，但也可以反映出：想要找出適合的配置及最佳性能需要結合實際，不斷的測試與改進，最終才能達到一個相對穩定的性能，雖然此時的性能未必是最佳的，但卻是能應對絕大多數情況的。