在目前流行的互聯網架構中，對一個應用來說，Tomcat是首，SSM是中，JVM是尾，我們通常對于SSM是比較了解的，而忽略了收尾，而Tomcat在目前的網絡編程中是舉足輕重的，但是我們其實對Tomcat中很多原理性的東西不太了解，如果能夠掌握Tomcat的原理，那么是非常有用的，下面講一下Tomcat性能優化的知識。

1、概述

本文檔主要介紹了Tomcat的性能調優的原理和方法。可作為公司技術人員為客戶Tomcat系統調優的技術指南，也可以提供給客戶的技術人員作為他們性能調優的指導手冊。

2、調優分類

由于Tomcat的運行依賴于JVM，從虛擬機的角度我們把Tomcat的調整分為外部環境調優和自身調優兩類來描述。

—2.1、外部環境調優

調整Tomcat運行環境的操作系統參數和運行Tomcat的java虛擬機參數。

——2.1.1、JAVA虛擬機性能優化

Tomcat需要依賴Java虛擬機運行。根據客戶選用的主機的操作系統選擇對應的 JDK的版本。無論哪個廠商的JDK，都建議使用最新的版本。

虛擬機可通過命令行的方式改變虛擬機使用內存的大小。如下表所示有兩個參用 來設置虛擬機使用內存的大小。

參數及描述：

-Xms JVM初始化堆的大小

-Xmx JVM堆的最大值

Tomcat默認可以使用的內存為128MB，在較大型的應用項目中，這點內存是不夠的，需要調大。

Windows下，在文件tomcat_home/bin/catalina.bat；

Unix下，在文件tomcat_home/bin/catalina.sh的前面，增加如下設置：

JAVA_OPTS=‘-Xms【初始化內存大小】 -Xmx【可以使用的最大內存】’'

需要把這個兩個參數值調大。例如：

JAVA_OPTS='-Xms256m -Xmx512m'

表示初始化內存為256MB，可以使用的最大內存為512MB。

另外需要考慮的是Java提供的垃圾回收機制。虛擬機的堆大小決定了虛擬機花費在收集垃圾上的時間和頻度。收集垃圾可以接受的速度與應用有關，應該通過分析實際的垃圾收集的時間和頻率來調整。

如果堆的空間很大，那么完全垃圾收集(FULL GC)就會很慢，但是頻度會降低。如果在客戶系統中把堆的大小和內存的需要一致，完全收集就很快，但是會更加頻繁。

調整堆大小的的目的是最小化垃圾收集的時間，以在特定的時間內最大化處理客戶的請求。對于SUN和HP等虛擬機，推薦將最小堆大小和最大堆大小設置為同一值，因為這樣可以避免浪費用于時常調整堆大小所需的 VM 資源。

當然，客戶系統如果用到IBM虛擬機，要特別的注意設置-Xms和-Xmx一樣大小會耽誤垃圾回收的開始直到堆滿，這樣第一次垃圾回收就會變成非常昂貴的操作。推薦把-Xms設置為應用所需的最小值，這樣會產生高效的垃圾回收。

——2.1.2、操作系統性能優化

以客戶系統為HP-UX為例。

HP系統中對Tomcat有影響的參數，其中：

max_thread_proc: 一個進程所能創建的線程的最大數

nkthread: 在系統上同時允許的核心線程的最大數

maxfiles上表給的建議是不是不合適？

如果在輸出里看到消息：java.lang.OutOfMemoryError: unable to create new native thread，則說明名為 max_thread_proc 的 Unix 內核設置過小。max_thread_proc 是單個進程中的最大線程數。 它必須大到能夠容納 Java 應用程序中的所有線程以及虛擬機本身中的部分額外線程。

查看核心參數：$ulimit -a

顯示輸出中的 nofiles 是指用戶的進程能同時打開的最大文件句柄數。如果日志中出現”two many open files”的異常，需要重點檢查這個參數。

coredump 參數是 core 文件最大值的，限制當進程 coredump 時將產生 core文件的大小不能超過這個最大值。如果在日志文件檢查時，發現 core文件不完整，需要增大這個參數值。執行 ulimit -n 命令可以設置 nofiles 參數，執行ulimit -c命令設置 core 文件最大值。

如果是在Windows操作系統上使用Tomcat，那么最好選擇服務器版本。因為在非服務器版本上，最終用戶授權數或者操作系統本身所能承受的用戶數、可用的網絡連接數或其它方面的一些方面都是有限制的。并且基于安全性的考慮，必須經常給操作系統打上最新的補丁。

——2.1.3、Tomcat與其它web服務器整合使用

雖然tomcat也可以作web服務器,但其處理靜態html的速度比不上apache,且其作為web服務器的功能遠不如apache,因此我們想把 apache和tomcat集成起來，將html與jsp的功能部分進行明確分工，讓tomcat只處理jsp部分，其它的由apache,IIS等這些 web服務器處理，由此大大節省了tomcat有限的工作線程 。

—2.2、自身調優

本節將說明Tomcat性能調優的技巧和方法，這些技巧和方法與操作系統或Java虛擬機的種類無關。以下方法都是針對Tomcat 性能自身調整的最佳方式。

——2.2.1、禁用DNS查詢

當web應用程序要記錄客戶端的信息時，它也會記錄客戶端的IP地址或者通過域名服務器查找機器名轉換為IP地址。DNS查詢需要占用網絡，并且包括可能從很多很遠的服務器或者不起作用的服務器上去獲取對應的IP的過程，這樣會消耗一定的時間。

為了消除DNS查詢對性能的影響我們可以關閉DNS查詢，方式是修改server.xml 文件中的enableLookups參數值。

不同的tomcat版本稍有不同：

Tomcat4

Tomcat5

除非客戶需要連接到站點的每個HTTP客戶端的機器名，否則我們建議在生產環境上關閉DNS查詢功能。可以通過Tomcat以外的方式來獲取機器名。這樣不僅節省了網絡帶寬、查詢時間和內存，而且更小的流量會使日志數據也會變得更少，顯而易見也節省了硬盤空間。對流量較小的站點來說禁用DNS查詢可能沒有大流量站點的效果明顯。

—2.2.2、調整線程數

另外一個可通過應用程序的連接器(Connector)進行性能控制的參數是創建的處理請求的線程數。Tomcat使用線程池加速響應速度來處理請求。在Java中線程是程序運行時的路徑，是在一個程序中與其它控制線程無關的、能夠獨立運行的代碼段。

它們共享相同的地址空間。多線程幫助程序員寫出CPU最大利用率的高效程序，使空閑時間保持最低，從而接受更多的請求。

Tomcat4中可以通過修改minProcessors和maxProcessors的值來控制線程數。這些值在安裝后就已經設定為默認值并且是足夠使用的，但是隨著站點的擴容而改大這些值。minProcessors服務器啟動時創建的處理請求的線程數應該足夠處理一個小量的負載。也就是說，如果一天內每秒僅發生5次單擊事件，并且每個請求任務處理需要1秒鐘，那么預先設置線程數為5就足夠了。

但在你的站點訪問量較大時就需要設置更大的線程數，指定為參數maxProcessors的值。maxProcessors的值也是有上限的，應防止流量不可控制(或者惡意的服務攻擊)，從而導致超出了虛擬機使用內存的大小。如果要加大并發連接數，應同時加大這兩個參數。web server允許的最大連接數還受制于操作系統的內核參數設置，通常Windows是2000個左右，Linux是1000個左右。

在Tomcat5對這些參數進行了調整，請看下表：

屬性名及描述：

maxThreads：Tomcat使用線程來處理接收的每個請求。這個值表示Tomcat可創建的最大的線程數。

acceptCount：指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理。

connnectionTimeout：網絡連接超時，單位：毫秒。設置為0表示永不超時，這樣設置有隱患的。通常可設置為30000毫秒。

minSpareThreads：Tomcat初始化時創建的線程數。

maxSpareThreads：一旦創建的線程超過這個值，Tomcat就會關閉不再需要的socket線程。

最好的方式是多設置幾次并且進行測試，觀察響應時間和內存使用情況。在不同的機器、操作系統或虛擬機組合的情況下可能會不同，而且并不是所有的web站點的流量都是一樣的，因此沒有一刀切的方案來確定線程數的值。

—2.2.3、加速JSP編譯速度

當第一次訪問一個JSP文件時，它會被轉換為Java servlet源碼，接著被編譯成Java字節碼。客戶工程師可以控制使用哪個編譯器，默認情況下，Tomcat使用命令行javac進行使用的編譯器。也可以使用更快的編譯器，這里將介紹如何優化它們。

[LD4] 另外一種方法是不要把所有的實現都使用JSP頁面，而是使用一些不同的java模板引擎變量。

在Tomcat 4.0中可以使用流行而且免費的Jikes編譯器。Jikes編譯器的速度要高于Sun的Java編譯器。首先要安裝Jikes(可訪問

裝好Jikes以后還需要設置讓JSP編譯servlet使用Jikes，需要修改web.xml文件中jspCompilerPlugin的值：

jsp

org.apache.jasper.servlet.JspServlet

logVerbosityLevel

WARNING

jspCompilerPlugin

org.apache.jasper.compiler.JikesJavaCompiler

classpath

/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:

/usr/local/lib/java/servletapi/servlet.jar

3

在Tomcat 4.1(或更高版本)，JSP的編譯由包含在Tomcat里面的Ant程序控制器直接執行。客戶開發人員需要在元素中定義一個名字叫”compiler”，并且在value中有一個支持編譯的編譯器名字，示例如下：

jsp

org.apache.jasper.servlet.JspServlet

logVerbosityLevel

WARNING

compiler

jikes

3

由于JSP頁面在第一次使用時已經被編譯，那么你可能希望在更新新的jsp頁面后馬上對它進行編譯。實際上，這個過程完全可以自動化，因為可以確認的是新的JSP頁面在生產服務器和在測試服務器上的運行效果是一樣的。

在Tomcat4的bin目錄下有一個名為jspc的腳本。它僅僅是運行翻譯階段，而不是編譯階段，使用它可以在當前目錄生成Java源文件。它是調試JSP頁面的一種有力的手段。

可以通過瀏覽器訪問再確認一下編譯的結果。這樣就確保了文件被轉換成servlet，被編譯了可直接執行。這樣也準確地模仿了真實用戶訪問JSP頁面，可以看到給用戶提供的功能。也抓緊這最后一刻修改出現的bug并且修改它。

Tomcat提供了一種通過請求來編譯JSP頁面的功能。客戶可以在瀏覽器地址欄中輸入http://localhost: 8080/examples/jsp/dates/date.jsp?jsp_precompile=true，這樣Tomcat就會編譯 data.jsp而不是執行它。此舉唾手可得，不失為一種檢驗頁面正確性的捷徑

—2.2.4、NIO 配置

NIO (No-blocking I/O)從JDK 1.4起，NIO API作為一個基于緩沖區，并能提供非阻塞I/O操作的API被引入[LD6] 。

TOMCAT可以支持高并發的企業級應用。其中有個很大的原因就是，配置良好的tomcat都會使用APR(Apache Portable Runtime),APR是Apache HTTP Server2.x的核心，它是高度可移植的本地庫，它使用高性能的UXIN I/O操作，低性能的java io操作。

但是APR對客戶開發人員而言可能稍稍有點難度，在很多OS平臺上，可能需要重新編譯APR。但是從Tomcat6.0以后, 客戶開發人員很容易就可以用NIO的技術來提升tomcat的并發處理能力。但是為什么NIO可以提升tomcat的并發處理能力呢，我們先來看一下java 傳統io與 java NIO的差別。

Java 傳統的IO操作都是阻塞式的(blocking I/O), 如果有socket的編程基礎，你會接觸過堵塞socket和非堵塞socket，堵塞socket就是在accept、read、write等IO操作的時候，如果沒有可用符合條件的資源，不馬上返回，一直等待直到有資源為止。

而非堵塞socket則是在執行select的時候，當沒有資源的時候堵塞，當有符合資源的時候，返回一個信號，然后程序就可以執行accept、read、write等操作，一般來說，如果使用堵塞socket，通常我們通常開一個線程accept socket，當讀完這次socket請求的時候，開一個單獨的線程處理這個socket請求；如果使用非堵塞socket，通常是只有一個線程，一開始是select狀，當有信號的時候可以通過多路復用(Multiplexing)技術傳遞給一個指定的線程池來處理請求，然后原來的線程繼續select狀態。

最簡單的多路復用技術可以通過java管道(Pipe)來實現。換句話說，如果客戶端的并發請求很大的時候，客戶系統可以使用少于客戶端并發請求的線程數來處理這些請求，而這些來不及立即處理的請求會被阻塞在java管道或者隊列里面，等待線程池的處理。

在web服務器上阻塞IO(BIO)與NIO一個比較重要的不同是，客戶系統使用BIO的時候往往會為每一個web請求引入多線程，每個web請求一個單獨的線程，所以并發量一旦上去了，線程數就上去了，CPU就忙著線程切換，所以BIO不合適高吞吐量、高可伸縮的web服務器；而NIO則是使用單線程(單個CPU)或者只使用少量的多線程(多CPU)來接受Socket，而由線程池來處理堵塞在pipe或者隊列里的請求。

這樣的話，只要OS可以接受TCP的連接，web服務器就可以處理該請求。大大提高了web服務器的可伸縮性。

客戶只需要在server.xml里把 HTTP Connector做如下更改：

connectionTimeout="20000"

redirectPort="8443" />

改為

connectionTimeout="20000"

redirectPort="8443" />

然后啟動服務器，如果出現org.apache.coyote.http11.Http11NioProtocol start的提示信息，表示NIO已經啟動。其他的配置請參考官方配置文檔。

—2.2.5、其它

前面我們提到過操作系統通過一些限制手段來防止惡意的服務攻擊，同樣Tomcat也提供了防止惡意攻擊或禁止某些機器訪問的設置。

Tomcat提供了兩個參數供你配置：RemoteHostValve 和RemoteAddrValve。

通過配置這兩個參數，可以讓你過濾來自請求的主機或IP地址，并允許或拒絕哪些主機/IP。與之類似的，在Apache的httpd文件里有對每個目錄的允許/拒絕指定。

例如你可以把Admin Web application設置成只允許本地訪問，設置如下：

allow=“127.0.0.1”deny=““/>

如果沒有給出允許主機的指定，那么與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。與之類似，如果沒有給出拒絕主機的指定，那么與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。

——3、負載均衡

在負載均衡的思路下，多臺服務器為對等方式，每臺服務器都具有同等的地位，可以單獨對外提供服務而無須其他服務器的輔助。通過負載分擔技術，將外部發送來的請求按一定規則分配到對稱結構中的某一臺服務器上，而接收到請求的服務器都獨立回應客戶機的請求。

提供服務的一組服務器組成了一個應用服務器集群(cluster)，集群下的對等多機環境可以增加系統的并發處理能力，和單臺機器出現故障系統的錯誤冗余能力；同時實現了負載均衡和系統高可靠性。

四種實現負載均衡的方式：

第一是通過DNS，但只能實現簡單的輪流分配，不能處理故障；

第二如果是基于MS IIS，Windows 2003 server本身就帶了負載均衡服務；

第三是硬件方式，通過交換機的功能或專門的負載均衡設備可以實現；

第四種是軟件方式，通過一臺負載均衡服務器進行，上面安裝軟件。使用Apache Httpd Server做負載平衡器。

客戶系統一般采用Apache httpd作為web服務器，即作為Tomcat的前端處理器，根據具體情況而定，有些情況下是不需要Apache httpd作為 web 服務器的，如系統展現沒有靜態頁面那就不需要Apache httpd，那時可以直接使用Tomcat作為web 服務器來使用。使用Apache httpd主要是它在處理靜態頁面方面的能力比Tomcat強多了。

——3.1.1配置負載均衡器

在apache下配置負載均衡器分為三步，注意每次修改httpd.conf和workers2.properties時不要忘了重新啟動apache。

第一步，安裝和調試apache

負載均衡器jk2模塊是apache www 服務的插件，所以配置負載均衡器就得先安裝apache。假設客戶下載的是windows版本 2.0.43，執行setup.exe并回答一些簡單問題就可完成apache的任務。

值得注意的是，安裝并啟動apache后如果apache對http://localhost/ 地址沒反應，你得修改apache安裝路徑下htdocs目錄下的index.html.xx文件，比如把index.html.en改成index.html。

第二步，安裝jk2

把下載到的 mod_jk2-2.0.43.dll改成mod_jk2.dll 放到apache的modules目錄下，修改apache的httpd.conf，即在LoadModule foo_module modules/mod_foo.so 行下插入mod_jk2模塊的裝載信息：

# Example:

# LoadModule foo_module modules/mod_foo.so

#

LoadModule jk2_module modules/mod_jk2.dll

第三步，配置jk2

jk2的配置全在一個配置文件中，文件名為workers2.properties，和apache 的httpd.conf放在同一個目錄下。以下是這個文件的內容：

#++++++++++++++++++++++++++++++++++++

# only at beginnin. In production uncomment it out

[logger.apache2]

level=DEBUG

#shm必須配

[shm]

file=D:\Program Files\Apache Group\Apache2\logs\shm.file

size=1048576

# 第一個tomcat 的地址

# Example socket channel, override port and host.

[channel.socket:tomcat1]

port=11009

host=127.0.0.1

# 定義第一個工作者指向第一個tomcat

# define the worker

[ajp13:tomcat1]

channel=channel.socket:tomcat1

#第二個tomcat 得地址

# Example socket channel, override port and host.

[channel.socket:tomcat2]

port=12009

host=10.1.36.123

# 定義第二個工作者指向第二個tomcat

# define the worker

[ajp13:tomcat2]

channel=channel.socket:tomcat2

#定義負載均衡器，使其包含兩個工作者

[lb:lb1]

worker=ajp13:tomcat2

worker=ajp13:tomcat1

#指定負載均衡器完成單一地址映射，使得apache 服務所在的uri全部指向 兩個tomcat 上的 root

# Uri mapping

[uri:/*]

group=lb:lb1

#++++++++++++++++++++++++++++++++++++++++++

—3.1.2、配置tomcat

同屬于一個集群下的兩個服務實體，要求功能的同一性，所以我們可先安裝和配置第一個tomcat，接著拷貝形成第二個tomcat，最后配置第二個tomcat。

安裝tomcat 非常簡單，本文就不再描述。我們假設第一個tomcat的安裝路徑為d:\tomcat1。

配置第一個tomcat：

tomcat 中的jk2 connector缺省端口為8009，為了在一臺機器上運行兩個tomcat，修改 D:\Tomcat1\conf\jk2.properties，設置jk2 connector的端口為11009，整個文件內容如下：

#++++++++++++++

channelSocket.port=11009

#++++++++++++++

為了讓一臺機器上運行兩個tomcat，修改server.conf的tomcat 停止指令監聽端口：

改為：

然后打開JK2 AJP connector ，關閉其它connector，下面是JK2 AJP 1.3的樣子，這里已把它的端口改為11009：

port="11009" minProcessors="5" maxProcessors="75"

enableLookups="true" redirectPort="8443"

acceptCount="10" debug="0" connectionTimeout="20000"

useURIValidationHack="false" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>

接著配置需要集群支持的webapp(比如examples) 的context。

添加如下manager：

className="org.apache.catalina.session.InMemoryReplicationManager"

protocolStack="UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=32)

:PING(timeout=3000; num_initial_members=6):FD(timeout=5000):VERIFY_SUSPECT(timeout=1500):

pbcast.STABLE(desired_avg_gossip=10000):pbcast.NAKACK(gc_lag=10;

retransmit_timeout=3000):UNICAST(timeout=5000;min_wait_time=2000):

MERGE2:FRAG:pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;

shun=false;print_local_addr=false)">

注意protocolStack的值必須在一行內寫完。

配置第二個tomcat：

把已經配好的第一個tomcat復制一份，形成第二個tomcat，假設路徑為d:\tomcat2。

修改D:\Tomcat2\conf\jk2.properties，設置jk2 connector的端口12009，整個文件內容如下：

#++++++++++++++

channelSocket.port=12009

#++++++++++++++

修改server.conf

有了第一個tomcat的配置我們只需修改server.conf的tomcat 停止指令監聽端口：

改為

然后設置JK2 AJP connector 端口為12009。

—3.1.3、運行測試

啟動apache，tomcat1和tomcat2。

我們先準備兩個文件，第一個文件為test.jsp，拷貝到第一個tomcat 的根web應用的目錄即d:\tomcat1\webapps\ROOT 下：

Tomcat 1

第二個文件也為test.jsp，拷貝到第二個tomcat 的根web應用的目錄即d:\tomcat2\webapps\ROOT 下：

center>

Tomcat 2

從不同的瀏覽器中多次輸入地址http://localhost/test.jsp 會看到不同的顏色，這表明apache中的jk2模塊起到了負載均衡的作用。

——4、容量計劃

容量計劃是在生產環境中使用Tomcat不得不提的提高性能的另一個重要的話題。如果你沒有對預期的網絡流量下的硬件和帶寬做考慮的話那么無論你如何做配置修改和測試都無濟于事。

這里先對提及的容量計劃作一個簡要的定義：容量計劃是指評估硬件、操作系統和網絡帶寬，確定應用服務的服務范圍，尋求適合需求和軟件特性的軟硬件的一項活動。因此這里所說的軟件不僅包括Tomcat，也包括與Tomcat結合使用的任何第三方web服務器軟件。

如果在購買軟硬件或部署系統前你對容量計劃一無所知，不知道現有的軟硬件環境能夠支撐多少的訪問量，甚至更糟直到你已經交付并且在生產環境上部署產品后才意識到配置有問題時再進行變更可能為時已晚。此時只能增加硬件投入，增加硬盤容量甚至購買更好的服務器。如果事先做了容量計劃那么就不會搞的如此焦頭爛額了。

我們這里只介紹與Tomcat相關的內容。

首先為了確定Tomcat使用機器的容量計劃，你應該從一下列表項目種著手研究和計劃：

—4.1.1、硬件

采用什么樣的硬件體系？需要多少臺計算機？使用一個大型的，還是使用多臺小型機？每個計算機上使用幾個CPU？使用多少內存？使用什么樣的存儲設備，I/O的處理速度有什么要求？怎樣維護這些計算機？不同的JVM在這些硬件上運行的效果如何?

—4.1.2、網絡帶寬

帶寬的使用極限是多少？web應用程序如何處理過多的請求？

—4.1.3、服務端操作系統

采用哪種操作系統作為站點服務器最好？在確定的操作系統上使用哪個JVM最好？例如，JVM在這種系統上是否支持本地多線程，對稱多處理？哪種系統可使web服務器更快、更穩定，并且更便宜。是否支持多CPU？

—4.1.4、Tomcat容量計劃

以下介紹針對Tomcat做容量計劃的步驟：

1) 量化負載。如果站點已經建立并運行，可以使用工具模仿用戶訪問，確定資源的需求量。

2) 針對測試結果或測試過程中進行分析。需要知道那些請求造成了負載過重或者使用過多的資源，并與其它請求做比較，這樣就確定了系統的瓶頸所在。例如：如果servlet在查詢數據庫的步驟上耗用較長的時間，那么就需要考慮使用緩沖池來降低響應時間。

3)確定性能最低標準。例如，你不想讓用戶花20秒來等待結果頁面的返回，也就是說甚至在達到訪問量的極限時，用戶等待的時間也不能超過20秒種(從點擊鏈接到看到返第一條返回數據)。這個時間中包含了數據庫查詢時間和文件訪問時間。同類產品性能在不同的公司可能有不同的標準，一般最好采取同行中的最低標準或對這個標準做出評估。

4)確定如何合理使用底層資源，并逐一進行測試。底層資源包括CPU、內存、存儲器、帶寬、操作系統、JVM等等。在各種生產環境上都按順序進行部署和測試，觀察是否符合需求。在測試Tomcat時盡量多采用幾種JVM，并且調整JVM使用內存和Tomcat線程池的大小進行測試。同時為了達到資源充分合理穩定地使用的效果，還需針對測試過程中出現的硬件系統瓶頸進行處理確定合理的資源配置。這個過程最為復雜，而且一般由于沒有可參考的值所以只能靠理論推斷和經驗總結。

5) 如果通過第4步的反復測試如果達到了最優的組合，就可以在相同的生產環境上部署產品了。

此外應牢記一定要文檔化你的測試過程和結果，因為此后可能還會進行測試，這樣就可以拿以前的測試結果作為參考。另外測試過程要反復多次進行，每次的條件可能都不一樣，因此只有記錄下來才能進行結果比較和最佳條件的選擇。

這樣客戶系統通過測試找到了最好的組合方式，各種資源得到了合理的配置，系統的性能得到了極大的提升。

總結

以上是生活随笔為你收集整理的限制tomcat带宽_必看的Tomcat性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。