Tomcat效能調整完整教程
Tomcat效能調整完整教程
一. 引言
效能測試與分析是軟體開發過程中介於架構和調整的一個廣泛並比較不容易理解的領域，更是一項較為複雜的活動。
就像下棋遊戲一樣，有效的效能測試 和分析只能在一個良好的計劃策略和具備了對不可預料事件的處理能力的條件下順
利地完成。一個下棋高手贏得比賽靠的不僅僅是對遊戲規則的認識，更是靠他的自 己的能力和不斷地專注於分析自己對
手的實力來更加有效地利用和發揮規則的作用。同樣一個優秀的效能測試和分析人員將要面對的是來自一個全新的應用
程式和環 境下帶來的整個專案的挑戰。本文中作者結合自己的使用經驗和參考文件，對Tomcat效能方面的調整做一簡要
的介紹，並給出Tomcat效能的測試、分析 和調整最佳化的一些方法。
二. 測量Web伺服器的效能
測量web伺服器的效能是一項讓人感到畏縮的任務，但是我們在這裡將給出一些需要注意的地方並且指點你瞭解其中
更多的細節性的內容。它不像一些 簡單的任務，如測量CPU的速率或者是測量程式佔用CPU的比例，web伺服器的效能最佳化
中包括許調整許多變數來達到目標。許多的測量策略中都包含了一個 看似簡單的瀏覽實際上是在向伺服器傳送大量的請求，
我們稱之為客戶端的程式，來測量響應時間。客戶端和伺服器端是在同一臺機器上嗎？伺服器在測試的時候還 執行著其它
的什麼程式嗎？客戶端和伺服器端的通訊是透過區域網，100baseT，10baseT還是使用調變解調器？客戶端是否一直重複請
求相同的頁 面，還是隨機地訪問不同的頁面？（這些影響到了服務快取的效能）客戶端傳送請求的有規律的還是突發的？
你是在最終的配置環境下執行服務的還是在除錯的配置 環境下執行服務的？客戶端請求中包含圖片還是隻有HTML頁面？是
否有請求是透過servlets和JSP的，CGI程式，服務端包含
（Server- Side Includes ，SSI是一個可以讓你使用動態HTML檔案的技術）？
所有這些都將是我們要關心的，並且幾乎我們不可能精確地把所有的問題都清楚地列出來。
1.壓力測試工具
“工欲善其事，必先利其器”，壓力測試只有藉助於一些工具才可得以實施。
大多數web壓力測試工具的實現原理都是透過重複的大量的頁面請求來模擬多使用者對被測系統的併發訪問，
以此達到產生壓力的目的。產生壓力的手段 都是透過錄制或者是編寫壓力指令碼，這些指令碼以多個程式或者
執行緒的形式在客戶端執行，這樣透過人為製造各種型別的壓力，我們可以觀察被測系統在各種壓力狀況
下的表現，從而定位系統瓶頸，作為系統調優的基礎。目前已經存在的效能測試工具林林總總，數量不下
一百種，從單一的開放原始碼的免費小工具如 Aapache 自帶的 web 效能測試工具 Apache Benchmark、開源
的Jmeter 到大而全的商業效能測試軟體如 Mercury 的 LoadRunner 等等。任何效能測試工具都有其優缺點，
我們可以根據實際情況挑選用最合適的工具。您可以在這裡找到一些web壓力測試工具
這裡我們所使用的工具要支援web應用服務認證才可以，要支援接收傳送cookies，不僅如此Tomcat支援多種
認證方式，比如基本認證、 基於表單的認證、相互認證和客戶端認證，而一些工具僅僅支援HTTP基本認證。
真實地模擬使用者認證是效能測試工具的一個重要的部分，因為認證機制將對一個 web站點的效能特徵產生重
要的影響。基於你在產品中使用的不同的認證方式，你需要從上面的工具列表中選擇使用這種特性的測試工具。
Apache Benchmark和http_load是命令列形式的工具，非常易於使用。Apache Benchmark可以模仿單獨的URL請求並且重複地執行，
可以使用不同的命令列引數來控制執行迭代的次數，併發使用者數等等。它的一個特點是可以週期性 地列印出處理過程的資訊，
而其它工具只能給出一個全域性的報告。
2.壓力測試工具介紹
1） Apache Benchmark
下面是執行Apache Benchmark的例子，響應時間非常長是因為它執行在一個配置非常低的系統上（Pentium 233）。
在這裡我們用它來訪問一個URL，模擬127個併發使用者重複執行1000次。
Root$ ab -k -n 1000 -c 127 -k
This is ApacheBench, Version 2.0.36 apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
Copyright (c) 1998-2002 The Apache Software Foundation,
Benchmarking tomcathost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: Apache
Server Hostname: tomcathost
Server Port: 8080
Document Path: /examples/date/date.jsp
Document Length: 701 bytes
Concurrency Level: 127
Time taken for tests: 53.162315 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Keep-Alive requests: 0
Total transferred: 861000 bytes
HTML transferred: 701000 bytes
Requests per second: 18.81[#/sec] (mean)
Time per request: 6.752(mean)
Time per request: 0.053(mean, across all concurrent requests)
Transfer rate: 15.80>Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 51 387.5 0 2999
Processing: 63 6228 2058.4 6208 12072
Waiting: 17 4236 1855.2 3283 9193
Total: 64 6280 2065.0 6285 12072
Percentage of the requests served within a certain time (ms)
50% 6285
66% 6397
75% 6580
80% 9076
90% 9080
95% 9089
98% 9265
99% 12071
100% 12072 (longest request)
2） Apache JMeter 中請求響應時間（圖略）
3） Mercury LoadRunner測試實時監控（圖略）
這三個工具是所有類似效能測試工具的典型代表，可以根據你自己的需要選擇不同的測試工具。
這裡不對以上工具做詳細的介紹，如果您對這些測試工具感興趣的話可以參閱附加資料。
3.效能評測技巧
1） 由於評測時要用到系統時鐘，所以當進行測試時不要執行無關的程式或程式，以免影響測試結果；
2） 如果對自己的程式進行了修改，並試圖改善它的效能，那麼在修改前後應分別測試一下程式碼的執行時間；
3） 儘量在完全一致的環境中進行每一次測試；
4） 如果可能，應設計一個不依賴於任何使用者輸入的測試，測試中使用的資料應完全一致，避免使用者的不同的反應或者資料的問題導致測試結果出現誤差；
5） 有可能您還需要考慮是在執行著的系統（包括作業系統和被測試的系統）上繼續進行測試還是重新啟動系統後再進行測試；
6） 對於有些系統第一次使用可能要進行初始化，這種工作在系統使用過程中僅進行一次，所以有必要在重啟系統後先進行一次初始化工作，然後進行效能測試。
三. 外部環境的調整
在Tomcat和應用程式進行了壓力測試後，如果您對應用程式的效能結果不太滿意，就可以採取一些效能調整措施了，
當然了前提是應用程式沒有問題，我們這裡只講Tomcat的調整。由於Tomcat的執行依賴於JVM，所以在這裡我們把
Tomcat的調整可以分為兩類來詳細描述：
外部環境調整
調整非Tomcat元件，例如Tomcat執行的作業系統和執行Tomcat的java虛擬機器。
自身調整
修改Tomcat自身的引數，調整Tomcat配置檔案中的引數。
下面我們將詳細講解外部環境調整的有關內容，Tomcat自身調整的內容將在第2部分中闡述。
1.JAVA虛擬機器效能最佳化
Tomcat本身不能直接在計算機上執行，需要依賴於硬體基礎之上的作業系統和一個java虛擬機器。您可以選擇自己的需要選擇不同的作業系統
和對應的JDK的版本（只要是符合Sun釋出的Java規範的），但我們推薦您使用Sun公司釋出的JDK。確保您所使用的版本是最新的，因為Sun公司和
其它一些公司一直在為提高效能而對java虛擬機器做一些升級改進。一些報告顯示JDK1.4在效能上比JDK1.3提高了將近10%到20%。
可以給Java虛擬機器設定使用的記憶體，但是如果你的選擇不對的話，虛擬機器不會補償。可透過命令列的方式改變虛擬機器使用記憶體的大小。如下表
所示有兩個引數用來設定虛擬機器使用記憶體的大小。
引數
描述
-Xms
JVM初始化堆的大小
-Xmx
JVM堆的最大值
這兩個值的大小一般根據需要進行設定。初始化堆的大小執行了虛擬機器在啟動時向系統申請的記憶體的大小。一般而言，
這個引數不重要。但是有 的應用程式在大負載的情況下會急劇地佔用更多的記憶體，此時這個引數就是顯得非常重要，
如果虛擬機器啟動時設定使用的記憶體比較小而在這種情況下有許多物件進行 初始化，虛擬機器就必須重複地增加記憶體來滿
足使用。由於這種原因，我們一般把-Xms和-Xmx設為一樣大，而堆的最大值受限於系統使用的實體記憶體。一般使 用數
據量較大的應用程式會使用持久物件，記憶體使用有可能迅速地增長。當應用程式需要的記憶體超出堆的最大值時虛擬機器就
會提示記憶體溢位，並且導致應用服務崩 潰。因此一般建議堆的最大值設定為可用記憶體的最大值的80%。
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提供的垃圾回收機制。虛擬機器的堆大小決定了虛擬機器花費在收集垃圾上的時間和頻度。
收集垃圾可以接受的速度與應用有關， 應該透過分析實際的垃圾收集的時間和頻率來調整。如果堆的大小很
大，那麼完全垃圾收集就會很慢，但是頻度會降低。如果你把堆的大小和記憶體的需要一致，完全 收集就很快，
但是會更加頻繁。調整堆大小的的目的是最小化垃圾收集的時間，以在特定的時間內最大化處理客戶的請求。
在基準測試的時候，為保證最好的效能， 要把堆的大小設大，保證垃圾收集不在整個基準測試的過程中出現。
如果系統花費很多的時間收集垃圾，請減小堆大小。一次完全的垃圾收集應該不超過 3-5 秒。如果垃圾收集
成為瓶頸，那麼需要指定代的大小，檢查垃圾收集的詳細輸出，研究 垃圾收集引數對效能的影響。一般說來，
你應該使用實體記憶體的 80% 作為堆大小。當增加處理器時，記得增加記憶體，因為分配可以並行進行，而垃圾
收集不是並行的。
2.作業系統效能最佳化
這裡說的作業系統是指執行web伺服器的系統軟體，當然，不同的作業系統是為不同的目的而設計的。比如OpenBSD是面向安全的，因此在它的
核心中有許多的限制來防止不同形式的服務攻擊（OpenBSD的一句座右銘是“預設是最安全的”）。這些限制或許更多地用來執行活躍的web伺服器。
而我們常用的Linux作業系統的目標是易用使用，因此它有著更高的限制。使用BSD核心的系統都帶有一個名為“Generic”的核心，表明 所有的
驅動器都靜態地與之相連。這樣就使系統易於使用，但是如果你要建立一個自定義的核心來加強其中某些限制，那就需要排除不需要的裝置。
Linux核心 中的許多驅動都是動態地載入的。但是換而言之，記憶體現在變得越來越便宜，所以因為載入額外的裝置驅動就顯得不是很重要的。
重要的是要有更多的記憶體，並且在 伺服器上騰出更多的可用記憶體。
小提示：雖然現在記憶體已經相當的便宜，但還是儘量不要購買便宜的記憶體。那些有牌子的記憶體雖然是貴一點，但是從可靠性上來說，價效比會更高一些。
如果是在Windows作業系統上使用Tomcat，那麼最好選擇伺服器版本。因為在非伺服器版本上，
終端使用者授權數或者作業系統本身所能承受的使用者數、可用的網路連線數或其它方面的一些
方面都是有限制的。並且基於安全性的考慮，必須經常給作業系統打上最新的補丁。
3.Tomcat與其它web伺服器整合使用
雖然tomcat也可以作web伺服器,但其處理靜態html的速度比不上apache,且其作為web伺服器的功能遠不如apache,因此 我們想把apache和tomcat整合起來，
將html與jsp的功能部分進行明確分工，讓tomcat只處理jsp部分，其它的由 apache,IIS等這些web伺服器處理，由此大大節省了tomcat有限的工作“執行緒”。
4.負載均衡
在負載均衡的思路下，多臺伺服器為對稱方式，每臺伺服器都具有同等的地位，可以單獨對外提供服務而無須其他伺服器的輔助。透過負載分擔技術，
將外部傳送來的請求按一定規則分配到對稱結構中的某一臺伺服器上，而接收到請求的伺服器都獨立回應客戶機的請求。
提供服務的一組伺服器組成了一個應用伺服器叢集(cluster)，並對外提供一個統一的地址。當一個服務請求被髮至該叢集時，
根據一定規則選擇一臺伺服器，並將服務轉定向給該伺服器承擔，即將負載進行均衡分攤。
透過應用負載均衡技術，使應用服務超過了一臺伺服器只能為有限使用者提供服務的限制，
可以利用多臺伺服器同時為大量使用者提供服務。當某臺伺服器出 現故障時，
負載均衡伺服器會自動進行檢測並停止將服務請求分發至該伺服器，
而由其他工作正常的伺服器繼續提供服務，
從而保證了服務的可靠性。
負載均衡實現的方式大概有四種：
第一是透過DNS，但只能實現簡單的輪流分配，不能處理故障，
第二如果是基於MS IIS，Windows 2003 server本身就帶了負載均衡服務，
第三是硬體方式，透過交換機的功能或專門的負載均衡裝置可以實現，
第四種是軟體方式，透過一臺負載均衡伺服器進行，
上面安裝軟體。使用Apache Httpd Server做負載平衡器，Tomcat叢集節點使用Tomcat就可以做到以上第四種方式。這種方式比較靈活，
成本相對也較低。另外一個很大的優點就是 可以根據應用的情況和伺服器的情況採取一些策略。
四. 自身調整
本節將向您詳細介紹一些加速可使Tomcat例項加速執行的技巧和方法，無論是在什麼作業系統或者何種Java虛擬機器上。
在有些情況下，您可能 沒有控制部署環境上的作業系統或者Java虛擬機器。在這種情況下，您就需要逐行了解以下的的
一些建議，然而你應該在修改後使之生效。我認為以下方法是 Tomcat效能自身調整的最佳方式。
1.禁用DNS查詢
當web應用程式向要記錄客戶端的資訊時，它也會記錄客戶端的IP地址或者透過域名伺服器查詢機器名轉換為IP地址。
DNS查詢需要佔用網路， 並且包括可能從很多很遠的伺服器或者不起作用的伺服器上去獲取對應的IP的過程，
這樣會消耗一定的時間。為了消除DNS查詢對效能的影響我們可以關閉 DNS查詢，
方式是修改server.xml檔案中的enableLookups引數值：
Tomcat4
Tomcat5
除非你需要連線到站點的每個HTTP客戶端的機器名，否則我們建議在生產環境上關閉DNS查詢功能。可以透過Tomcat以外的方式來獲取機器名。
這樣不僅節省了網路頻寬、查詢時間和記憶體，而且更小的流量會使日誌資料也會變得更少，顯而易見也節省了硬碟空間。對流量較小的站點來
說禁用DNS查詢 可能沒有大流量站點的效果明顯，但是此舉仍不失為一良策。誰又見到一個低流量的網站一夜之間就流量大增呢？
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站點的流量都是一樣的，因此沒有一刀切的方案來確定執行緒數的值。
3.加速JSP編譯速度
當第一次訪問一個JSP檔案時，它會被轉換為Java serverlet原始碼，接著被編譯成Java位元組碼。你可以控制使用哪個編譯器，
預設情況下，Tomcat使用使用命令列javac進行使用的編譯器。 也可以使用更快的編譯器，但是這裡我們將介紹如何最佳化它們。
另外一種方法是不要把所有的實現都使用JSP頁面，而是使用一些不同的java模板引擎變數。顯然這是一個跨越很大的決定，
但是事實證明至少這 種方法是隻得研究的。如果你想了解更多有關在Tomcat可使用的模板語言，你可以參考Jason Hunter和
William Crawford合著的《Java Servlet Programming 》一書（O'Reilly公司出版）。
在Tomcat 4.0中可以使用流行而且免費的Jikes編譯器。Jikes編譯器的速度要由於Sun的Java編譯器。
首先要安裝Jikes（可訪問 獲得更多的資訊），接著需要在環
境變數中設定JIKESPATH包含系統執行時所需的JAR檔案。裝好Jikes以後還需要設定讓JSP編譯servlet使
用Jikes，需要修改web.xml檔案中jspCompilerPlugin的值：
jsp
org.apache.jasper.servlet.JspServlet
logVerbosityLevel
WARNING
jspCompilerPlugin
org.apache.jasper.compiler.JikesJavaCompiler
<!--
org.apache.catalina.jsp_classpath
-->
classpath
/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
/usr/local/lib/java/servletapi/servlet.ja
r
3
在Tomcat 4.1（或更高版本），JSP的編譯由包含在Tomcat裡面的Ant程式控制器直接執行。這聽起
來有一點點奇怪，但這正是Ant有意為之的一部分，有一 個API文件指導開發者在沒有啟動一個新的JVM
的情況下，使用Ant。這是使用Ant進行Java開發的一大優勢。另外，這也意味著你現在能夠在Ant 中使
用任何javac支援的編譯方式，這裡有一個關於Apache Ant使用手冊的javac page列表。使用起來是容
易的，因為你只需要在 元素中定義一個名字叫“compiler”，並且在value中有一個支援編譯的編譯器名
字，示例如下：
jsp
org.apache.jasper.servlet.JspServlet
logVerbosityLevel
WARNING
compiler
jikes
3
Ant可用的編譯器
名稱
別名
呼叫的編譯器
classic
javac1.1, javac1.2
Standard JDK 1.1/1.2 compiler
modern
javac1.3, javac1.4
Standard JDK 1.3/1.4 compiler
jikes
The Jikes compiler
JVC Microsoft
Microsoft command-line compiler from the Microsoft SDK for Java/Visual J++
KJC The kopi compiler
GCJ The gcj compiler (included as part of gcc)
SJ Symantec
Symantec's Java compiler
extJavac
Runs either the modern or classic compiler in a JVM of its own
由於JSP頁面在第一次使用時已經被編譯，那麼你可能希望在更新新的jsp頁面後馬上對它進行編譯。
實際上，這個過程完全可以自動化，因為可以確認的是新的JSP頁面在生產伺服器和在測試伺服器
上的執行效果是一樣的。
在Tomcat4的bin目錄下有一個名為jspc的指令碼。它僅僅是執行翻譯階段，而不是編譯階段，使用它
可以在當前目錄生成Java原始檔。它是除錯JSP頁面的一種有力的手段。
可以透過瀏覽器訪問再確認一下編譯的結果。這樣就確保了檔案被轉換成serverlet，被編譯了可
直接執行。這樣也準確地模仿了真實使用者訪問JSP頁面，可以看到給使用者提供的功能。也抓緊這最
後一刻修改出現的bug並且修改它J
Tomcat提供了一種透過請求來編譯JSP頁面的功能。例如，你可以在瀏覽器位址列中輸入
，
這樣Tomcat就會編譯data.jsp而不是執行它。此舉唾手可得，不失為一種檢驗頁面正確性的捷徑。
4. 其它
前面我們提到過作業系統透過一些限制手段來防止惡意的服務攻擊，
同樣Tomcat也提供了防止惡意攻擊或禁止某些機器訪問的設定。
Tomcat提供了兩個引數供你配置：RemoteHostValve 和RemoteAddrValve。
透過配置這兩個引數，可以讓你過濾來自請求的主機或IP地址，並允許或拒絕哪些主機/IP。
與之類似的，在Apache的httpd檔案裡有對每個目錄的允許/拒絕指定。
例如你可以把Admin Web application設定成只允許本地訪問，設定如下：
allow="127.0.0.1" deny=""/>
如果沒有給出允許主機的指定，那麼與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。
與之類似，如果沒有給出拒絕主機的指定，那麼與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。
五. 容量計劃
容量計劃是在生產環境中使用Tomcat不得不提的提高效能的另一個重要的話題。
如果你沒有對預期的網路流量下的硬體和頻寬做考慮的話那麼無論你如何做配置修改和測試都無濟於事。
這裡先對提及的容量計劃作一個簡要的定義：容量計劃是指評估硬體、作業系統和網路頻寬，
確定應用服務的服務範圍，尋求適合需求和軟體特性的軟硬體的一項活動。因此這裡所說的軟體不僅包括Tomcat，
也包括與Tomcat結合使用的任何第三方web伺服器軟體。
如果在購買軟硬體或部署系統前你對容量計劃一無所知，不知道現有的軟硬體環境能夠支撐多少的訪問量，
甚至更糟直到你已經交付並且在生產環境上部 署產品後才意識到配置有問題時再進行變更可能為時已晚。此時
只能增加硬體投入，增加硬碟容量甚至購買更好的伺服器。如果事先做了容量計劃那麼就不會搞的如 此焦頭
爛額了。
我們這裡只介紹與Tomcat相關的內容。
首先為了確定Tomcat使用機器的容量計劃，你應該從一下列表專案種著手研究和計劃：
1. 硬體
採用什麼樣的硬體體系？需要多少臺計算機？使用一個大型的，還是使用多臺小型機？每個計算機上使用幾個CPU？使用多少記憶體？
使用什麼樣的儲存 裝置，I/O的處理速度有什麼要求？怎樣維護這些計算機？不同的JVM在這些硬體上執行的效果如何
（比如IBM AIX系統只能在其設計的硬體系統上執行）
2. 網路頻寬
頻寬的使用極限是多少？web應用程式如何處理過多的請求？
3. 服務端作業系統
採用哪種作業系統作為站點伺服器最好？在確定的作業系統上使用哪個JVM最好？例如，JVM在這種系統上是否支援本地多執行緒，
對稱多處理？哪種系統可使web伺服器更快、更穩定，並且更便宜。是否支援多CPU？
4. Tomcat容量計劃
以下介紹針對Tomcat做容量計劃的步驟：
1） 量化負載。如果站點已經建立並執行，可以使用前面介紹的工具模仿使用者訪問，確定資源的需求量。
2） 針對測試結果或測試過程中進行分析。需要知道那些請求造成了負載過重或者使用過多的資源，並與其它請求做比較，
這樣就確定了系統的瓶頸所在。例如：如果servlet在查詢資料庫的步驟上耗用較長的時間，那麼就需要考慮使用緩衝池來降低響應時間。
3） 確定效能最低標準。例如，你不想讓使用者花20秒來等待結果頁面的返回，也就是說甚至在達到訪問量的極限時，使用者等待的時間也不能
超過20秒種（從點選連結 到看到返第一條返回資料）。這個時間中包含了資料庫查詢時間和檔案訪問時間。同類產品效能在不同的公司
可能有不同的標準，一般最好採取同行中的最低標準或 對這個標準做出評估。
4） 確定如何合理使用底層資源，並逐一進行測試。底層資源包括CPU、記憶體、儲存器、頻寬、作業系統、JVM等等。在各種生產環境上都按
順序進行部署和測試， 觀察是否符合需求。在測試Tomcat時儘量多采用幾種JVM，並且調整JVM使用記憶體和Tomcat執行緒池的大小進行測試。
同時為了達到資源充分合理穩 定地使用的效果，還需針對測試過程中出現的硬體系統瓶頸進行處理確定合理的資源配置。這個過程最為
複雜，而且一般由於沒有可參考的值所以只能靠理論推斷和 經驗總結。
5） 如果透過第4步的反覆測試如果達到了最優的組合，就可以在相同的生產環境上部署產品了。
此外應牢記一定要文件化你的測試過程和結果，因為此後可能還會進行測試，這樣就可以拿以前的測試結果做為參考。另外測試過程要反覆
多次進行，每次的條件可能都不一樣，因此只有記錄下來才能進行結果比較和最佳條件的選擇。
這樣我們透過測試找到了最好的組合方式，各種資源得到了合理的配置，系統的效能得到了極大的提升。
六. 附加資料
很顯然本文也很難全面而詳盡地闡述效能最佳化過程。如果你進行更多研究的話可能會把效能調優做的更好，比如Java程式的效能調整、作業系統的調整、
各種複雜環境與應用系統和其它所有與應用程式相關的東西。在這裡提供一些文中提到的一些資源、文中提到的相關內容的連結以及本文的一些參考資料。
1. Web效能測試資料及工具
1） Jmeter Wiki首頁，Jmeter為一個開源的100%Java開發的效能測試工具
2） Apache Benchmark使用說明
3） 一些Java相關測試工具的介紹，包含可以與Tomcat整合進行測試的工具
http://blog.csdn.net/wyingquan/
4） LoadRunner? 是一種預測系統行為和效能的工業標準級負載測試工具。它透過模擬資料以千萬計使用者來實施併發負載來對整個企業架構進行測試，
來幫助您更快的查詢和發現問題。
http://www.mercury.com/us/products/performance-center/loadrunner/
2. 文中介紹的相關內容的介紹
1） Apache 2.x + Tomcat 4.x做負載均衡，描述瞭如何利用jk配置叢集的負載均衡。
2） 容量計劃的制定，收集了許多有關制定web站點容量計劃的例子：
3） 評測Tomcat5負載平衡與叢集，
4） Apache與Tomcat的安裝與整合之整合篇
5） 效能測試工具之研究，介紹了效能測試工具的原理與思路
6） Java的記憶體洩漏
7） Web伺服器和應用程式伺服器有什麼區別？
8） 詳細講解效能中資料庫叢集的問題
（完）
一. 引言
效能測試與分析是軟體開發過程中介於架構和調整的一個廣泛並比較不容易理解的領域，更是一項較為複雜的活動。
就像下棋遊戲一樣，有效的效能測試 和分析只能在一個良好的計劃策略和具備了對不可預料事件的處理能力的條件下順
利地完成。一個下棋高手贏得比賽靠的不僅僅是對遊戲規則的認識，更是靠他的自 己的能力和不斷地專注於分析自己對
手的實力來更加有效地利用和發揮規則的作用。同樣一個優秀的效能測試和分析人員將要面對的是來自一個全新的應用
程式和環 境下帶來的整個專案的挑戰。本文中作者結合自己的使用經驗和參考文件，對Tomcat效能方面的調整做一簡要
的介紹，並給出Tomcat效能的測試、分析 和調整最佳化的一些方法。
二. 測量Web伺服器的效能
測量web伺服器的效能是一項讓人感到畏縮的任務，但是我們在這裡將給出一些需要注意的地方並且指點你瞭解其中
更多的細節性的內容。它不像一些 簡單的任務，如測量CPU的速率或者是測量程式佔用CPU的比例，web伺服器的效能最佳化
中包括許調整許多變數來達到目標。許多的測量策略中都包含了一個 看似簡單的瀏覽實際上是在向伺服器傳送大量的請求，
我們稱之為客戶端的程式，來測量響應時間。客戶端和伺服器端是在同一臺機器上嗎？伺服器在測試的時候還 執行著其它
的什麼程式嗎？客戶端和伺服器端的通訊是透過區域網，100baseT，10baseT還是使用調變解調器？客戶端是否一直重複請
求相同的頁 面，還是隨機地訪問不同的頁面？（這些影響到了服務快取的效能）客戶端傳送請求的有規律的還是突發的？
你是在最終的配置環境下執行服務的還是在除錯的配置 環境下執行服務的？客戶端請求中包含圖片還是隻有HTML頁面？是
否有請求是透過servlets和JSP的，CGI程式，服務端包含
（Server- Side Includes ，SSI是一個可以讓你使用動態HTML檔案的技術）？
所有這些都將是我們要關心的，並且幾乎我們不可能精確地把所有的問題都清楚地列出來。
1.壓力測試工具
“工欲善其事，必先利其器”，壓力測試只有藉助於一些工具才可得以實施。
大多數web壓力測試工具的實現原理都是透過重複的大量的頁面請求來模擬多使用者對被測系統的併發訪問，
以此達到產生壓力的目的。產生壓力的手段 都是透過錄制或者是編寫壓力指令碼，這些指令碼以多個程式或者
執行緒的形式在客戶端執行，這樣透過人為製造各種型別的壓力，我們可以觀察被測系統在各種壓力狀況
下的表現，從而定位系統瓶頸，作為系統調優的基礎。目前已經存在的效能測試工具林林總總，數量不下
一百種，從單一的開放原始碼的免費小工具如 Aapache 自帶的 web 效能測試工具 Apache Benchmark、開源
的Jmeter 到大而全的商業效能測試軟體如 Mercury 的 LoadRunner 等等。任何效能測試工具都有其優缺點，
我們可以根據實際情況挑選用最合適的工具。您可以在這裡找到一些web壓力測試工具
這裡我們所使用的工具要支援web應用服務認證才可以，要支援接收傳送cookies，不僅如此Tomcat支援多種
認證方式，比如基本認證、 基於表單的認證、相互認證和客戶端認證，而一些工具僅僅支援HTTP基本認證。
真實地模擬使用者認證是效能測試工具的一個重要的部分，因為認證機制將對一個 web站點的效能特徵產生重
要的影響。基於你在產品中使用的不同的認證方式，你需要從上面的工具列表中選擇使用這種特性的測試工具。
Apache Benchmark和http_load是命令列形式的工具，非常易於使用。Apache Benchmark可以模仿單獨的URL請求並且重複地執行，
可以使用不同的命令列引數來控制執行迭代的次數，併發使用者數等等。它的一個特點是可以週期性 地列印出處理過程的資訊，
而其它工具只能給出一個全域性的報告。
2.壓力測試工具介紹
1） Apache Benchmark
下面是執行Apache Benchmark的例子，響應時間非常長是因為它執行在一個配置非常低的系統上（Pentium 233）。
在這裡我們用它來訪問一個URL，模擬127個併發使用者重複執行1000次。
Root$ ab -k -n 1000 -c 127 -k
This is ApacheBench, Version 2.0.36 apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
Copyright (c) 1998-2002 The Apache Software Foundation,
Benchmarking tomcathost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: Apache
Server Hostname: tomcathost
Server Port: 8080
Document Path: /examples/date/date.jsp
Document Length: 701 bytes
Concurrency Level: 127
Time taken for tests: 53.162315 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Keep-Alive requests: 0
Total transferred: 861000 bytes
HTML transferred: 701000 bytes
Requests per second: 18.81[#/sec] (mean)
Time per request: 6.752(mean)
Time per request: 0.053(mean, across all concurrent requests)
Transfer rate: 15.80>Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 51 387.5 0 2999
Processing: 63 6228 2058.4 6208 12072
Waiting: 17 4236 1855.2 3283 9193
Total: 64 6280 2065.0 6285 12072
Percentage of the requests served within a certain time (ms)
50% 6285
66% 6397
75% 6580
80% 9076
90% 9080
95% 9089
98% 9265
99% 12071
100% 12072 (longest request)
2） Apache JMeter 中請求響應時間（圖略）
3） Mercury LoadRunner測試實時監控（圖略）
這三個工具是所有類似效能測試工具的典型代表，可以根據你自己的需要選擇不同的測試工具。
這裡不對以上工具做詳細的介紹，如果您對這些測試工具感興趣的話可以參閱附加資料。
3.效能評測技巧
1） 由於評測時要用到系統時鐘，所以當進行測試時不要執行無關的程式或程式，以免影響測試結果；
2） 如果對自己的程式進行了修改，並試圖改善它的效能，那麼在修改前後應分別測試一下程式碼的執行時間；
3） 儘量在完全一致的環境中進行每一次測試；
4） 如果可能，應設計一個不依賴於任何使用者輸入的測試，測試中使用的資料應完全一致，避免使用者的不同的反應或者資料的問題導致測試結果出現誤差；
5） 有可能您還需要考慮是在執行著的系統（包括作業系統和被測試的系統）上繼續進行測試還是重新啟動系統後再進行測試；
6） 對於有些系統第一次使用可能要進行初始化，這種工作在系統使用過程中僅進行一次，所以有必要在重啟系統後先進行一次初始化工作，然後進行效能測試。
三. 外部環境的調整
在Tomcat和應用程式進行了壓力測試後，如果您對應用程式的效能結果不太滿意，就可以採取一些效能調整措施了，
當然了前提是應用程式沒有問題，我們這裡只講Tomcat的調整。由於Tomcat的執行依賴於JVM，所以在這裡我們把
Tomcat的調整可以分為兩類來詳細描述：
外部環境調整
調整非Tomcat元件，例如Tomcat執行的作業系統和執行Tomcat的java虛擬機器。
自身調整
修改Tomcat自身的引數，調整Tomcat配置檔案中的引數。
下面我們將詳細講解外部環境調整的有關內容，Tomcat自身調整的內容將在第2部分中闡述。
1.JAVA虛擬機器效能最佳化
Tomcat本身不能直接在計算機上執行，需要依賴於硬體基礎之上的作業系統和一個java虛擬機器。您可以選擇自己的需要選擇不同的作業系統
和對應的JDK的版本（只要是符合Sun釋出的Java規範的），但我們推薦您使用Sun公司釋出的JDK。確保您所使用的版本是最新的，因為Sun公司和
其它一些公司一直在為提高效能而對java虛擬機器做一些升級改進。一些報告顯示JDK1.4在效能上比JDK1.3提高了將近10%到20%。
可以給Java虛擬機器設定使用的記憶體，但是如果你的選擇不對的話，虛擬機器不會補償。可透過命令列的方式改變虛擬機器使用記憶體的大小。如下表
所示有兩個引數用來設定虛擬機器使用記憶體的大小。
引數
描述
-Xms
JVM初始化堆的大小
-Xmx
JVM堆的最大值
這兩個值的大小一般根據需要進行設定。初始化堆的大小執行了虛擬機器在啟動時向系統申請的記憶體的大小。一般而言，
這個引數不重要。但是有 的應用程式在大負載的情況下會急劇地佔用更多的記憶體，此時這個引數就是顯得非常重要，
如果虛擬機器啟動時設定使用的記憶體比較小而在這種情況下有許多物件進行 初始化，虛擬機器就必須重複地增加記憶體來滿
足使用。由於這種原因，我們一般把-Xms和-Xmx設為一樣大，而堆的最大值受限於系統使用的實體記憶體。一般使 用數
據量較大的應用程式會使用持久物件，記憶體使用有可能迅速地增長。當應用程式需要的記憶體超出堆的最大值時虛擬機器就
會提示記憶體溢位，並且導致應用服務崩 潰。因此一般建議堆的最大值設定為可用記憶體的最大值的80%。
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提供的垃圾回收機制。虛擬機器的堆大小決定了虛擬機器花費在收集垃圾上的時間和頻度。
收集垃圾可以接受的速度與應用有關， 應該透過分析實際的垃圾收集的時間和頻率來調整。如果堆的大小很
大，那麼完全垃圾收集就會很慢，但是頻度會降低。如果你把堆的大小和記憶體的需要一致，完全 收集就很快，
但是會更加頻繁。調整堆大小的的目的是最小化垃圾收集的時間，以在特定的時間內最大化處理客戶的請求。
在基準測試的時候，為保證最好的效能， 要把堆的大小設大，保證垃圾收集不在整個基準測試的過程中出現。
如果系統花費很多的時間收集垃圾，請減小堆大小。一次完全的垃圾收集應該不超過 3-5 秒。如果垃圾收集
成為瓶頸，那麼需要指定代的大小，檢查垃圾收集的詳細輸出，研究 垃圾收集引數對效能的影響。一般說來，
你應該使用實體記憶體的 80% 作為堆大小。當增加處理器時，記得增加記憶體，因為分配可以並行進行，而垃圾
收集不是並行的。
2.作業系統效能最佳化
這裡說的作業系統是指執行web伺服器的系統軟體，當然，不同的作業系統是為不同的目的而設計的。比如OpenBSD是面向安全的，因此在它的
核心中有許多的限制來防止不同形式的服務攻擊（OpenBSD的一句座右銘是“預設是最安全的”）。這些限制或許更多地用來執行活躍的web伺服器。
而我們常用的Linux作業系統的目標是易用使用，因此它有著更高的限制。使用BSD核心的系統都帶有一個名為“Generic”的核心，表明 所有的
驅動器都靜態地與之相連。這樣就使系統易於使用，但是如果你要建立一個自定義的核心來加強其中某些限制，那就需要排除不需要的裝置。
Linux核心 中的許多驅動都是動態地載入的。但是換而言之，記憶體現在變得越來越便宜，所以因為載入額外的裝置驅動就顯得不是很重要的。
重要的是要有更多的記憶體，並且在 伺服器上騰出更多的可用記憶體。
小提示：雖然現在記憶體已經相當的便宜，但還是儘量不要購買便宜的記憶體。那些有牌子的記憶體雖然是貴一點，但是從可靠性上來說，價效比會更高一些。
如果是在Windows作業系統上使用Tomcat，那麼最好選擇伺服器版本。因為在非伺服器版本上，
終端使用者授權數或者作業系統本身所能承受的使用者數、可用的網路連線數或其它方面的一些
方面都是有限制的。並且基於安全性的考慮，必須經常給作業系統打上最新的補丁。
3.Tomcat與其它web伺服器整合使用
雖然tomcat也可以作web伺服器,但其處理靜態html的速度比不上apache,且其作為web伺服器的功能遠不如apache,因此 我們想把apache和tomcat整合起來，
將html與jsp的功能部分進行明確分工，讓tomcat只處理jsp部分，其它的由 apache,IIS等這些web伺服器處理，由此大大節省了tomcat有限的工作“執行緒”。
4.負載均衡
在負載均衡的思路下，多臺伺服器為對稱方式，每臺伺服器都具有同等的地位，可以單獨對外提供服務而無須其他伺服器的輔助。透過負載分擔技術，
將外部傳送來的請求按一定規則分配到對稱結構中的某一臺伺服器上，而接收到請求的伺服器都獨立回應客戶機的請求。
提供服務的一組伺服器組成了一個應用伺服器叢集(cluster)，並對外提供一個統一的地址。當一個服務請求被髮至該叢集時，
根據一定規則選擇一臺伺服器，並將服務轉定向給該伺服器承擔，即將負載進行均衡分攤。
透過應用負載均衡技術，使應用服務超過了一臺伺服器只能為有限使用者提供服務的限制，
可以利用多臺伺服器同時為大量使用者提供服務。當某臺伺服器出 現故障時，
負載均衡伺服器會自動進行檢測並停止將服務請求分發至該伺服器，
而由其他工作正常的伺服器繼續提供服務，
從而保證了服務的可靠性。
負載均衡實現的方式大概有四種：
第一是透過DNS，但只能實現簡單的輪流分配，不能處理故障，
第二如果是基於MS IIS，Windows 2003 server本身就帶了負載均衡服務，
第三是硬體方式，透過交換機的功能或專門的負載均衡裝置可以實現，
第四種是軟體方式，透過一臺負載均衡伺服器進行，
上面安裝軟體。使用Apache Httpd Server做負載平衡器，Tomcat叢集節點使用Tomcat就可以做到以上第四種方式。這種方式比較靈活，
成本相對也較低。另外一個很大的優點就是 可以根據應用的情況和伺服器的情況採取一些策略。
四. 自身調整
本節將向您詳細介紹一些加速可使Tomcat例項加速執行的技巧和方法，無論是在什麼作業系統或者何種Java虛擬機器上。
在有些情況下，您可能 沒有控制部署環境上的作業系統或者Java虛擬機器。在這種情況下，您就需要逐行了解以下的的
一些建議，然而你應該在修改後使之生效。我認為以下方法是 Tomcat效能自身調整的最佳方式。
1.禁用DNS查詢
當web應用程式向要記錄客戶端的資訊時，它也會記錄客戶端的IP地址或者透過域名伺服器查詢機器名轉換為IP地址。
DNS查詢需要佔用網路， 並且包括可能從很多很遠的伺服器或者不起作用的伺服器上去獲取對應的IP的過程，
這樣會消耗一定的時間。為了消除DNS查詢對效能的影響我們可以關閉 DNS查詢，
方式是修改server.xml檔案中的enableLookups引數值：
Tomcat4
Tomcat5
除非你需要連線到站點的每個HTTP客戶端的機器名，否則我們建議在生產環境上關閉DNS查詢功能。可以透過Tomcat以外的方式來獲取機器名。
這樣不僅節省了網路頻寬、查詢時間和記憶體，而且更小的流量會使日誌資料也會變得更少，顯而易見也節省了硬碟空間。對流量較小的站點來
說禁用DNS查詢 可能沒有大流量站點的效果明顯，但是此舉仍不失為一良策。誰又見到一個低流量的網站一夜之間就流量大增呢？
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站點的流量都是一樣的，因此沒有一刀切的方案來確定執行緒數的值。
3.加速JSP編譯速度
當第一次訪問一個JSP檔案時，它會被轉換為Java serverlet原始碼，接著被編譯成Java位元組碼。你可以控制使用哪個編譯器，
預設情況下，Tomcat使用使用命令列javac進行使用的編譯器。 也可以使用更快的編譯器，但是這裡我們將介紹如何最佳化它們。
另外一種方法是不要把所有的實現都使用JSP頁面，而是使用一些不同的java模板引擎變數。顯然這是一個跨越很大的決定，
但是事實證明至少這 種方法是隻得研究的。如果你想了解更多有關在Tomcat可使用的模板語言，你可以參考Jason Hunter和
William Crawford合著的《Java Servlet Programming 》一書（O'Reilly公司出版）。
在Tomcat 4.0中可以使用流行而且免費的Jikes編譯器。Jikes編譯器的速度要由於Sun的Java編譯器。
首先要安裝Jikes（可訪問 獲得更多的資訊），接著需要在環
境變數中設定JIKESPATH包含系統執行時所需的JAR檔案。裝好Jikes以後還需要設定讓JSP編譯servlet使
用Jikes，需要修改web.xml檔案中jspCompilerPlugin的值：
org.apache.jasper.servlet.JspServlet
org.apache.jasper.compiler.JikesJavaCompiler
<!--
org.apache.catalina.jsp_classpath
/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
/usr/local/lib/java/servletapi/servlet.ja
r
在Tomcat 4.1（或更高版本），JSP的編譯由包含在Tomcat裡面的Ant程式控制器直接執行。這聽起
來有一點點奇怪，但這正是Ant有意為之的一部分，有一 個API文件指導開發者在沒有啟動一個新的JVM
的情況下，使用Ant。這是使用Ant進行Java開發的一大優勢。另外，這也意味著你現在能夠在Ant 中使
用任何javac支援的編譯方式，這裡有一個關於Apache Ant使用手冊的javac page列表。使用起來是容
易的，因為你只需要在 元素中定義一個名字叫“compiler”，並且在value中有一個支援編譯的編譯器名
字，示例如下：
org.apache.jasper.servlet.JspServlet
Ant可用的編譯器
名稱
別名
呼叫的編譯器
classic
javac1.1, javac1.2
Standard JDK 1.1/1.2 compiler
modern
javac1.3, javac1.4
Standard JDK 1.3/1.4 compiler
jikes
The Jikes compiler
JVC Microsoft
Microsoft command-line compiler from the Microsoft SDK for Java/Visual J++
KJC The kopi compiler
GCJ The gcj compiler (included as part of gcc)
SJ Symantec
Symantec's Java compiler
extJavac
Runs either the modern or classic compiler in a JVM of its own
由於JSP頁面在第一次使用時已經被編譯，那麼你可能希望在更新新的jsp頁面後馬上對它進行編譯。
實際上，這個過程完全可以自動化，因為可以確認的是新的JSP頁面在生產伺服器和在測試伺服器
上的執行效果是一樣的。
在Tomcat4的bin目錄下有一個名為jspc的指令碼。它僅僅是執行翻譯階段，而不是編譯階段，使用它
可以在當前目錄生成Java原始檔。它是除錯JSP頁面的一種有力的手段。
可以透過瀏覽器訪問再確認一下編譯的結果。這樣就確保了檔案被轉換成serverlet，被編譯了可
直接執行。這樣也準確地模仿了真實使用者訪問JSP頁面，可以看到給使用者提供的功能。也抓緊這最
後一刻修改出現的bug並且修改它J
Tomcat提供了一種透過請求來編譯JSP頁面的功能。例如，你可以在瀏覽器位址列中輸入
，
這樣Tomcat就會編譯data.jsp而不是執行它。此舉唾手可得，不失為一種檢驗頁面正確性的捷徑。
4. 其它
前面我們提到過作業系統透過一些限制手段來防止惡意的服務攻擊，
同樣Tomcat也提供了防止惡意攻擊或禁止某些機器訪問的設定。
Tomcat提供了兩個引數供你配置：RemoteHostValve 和RemoteAddrValve。
透過配置這兩個引數，可以讓你過濾來自請求的主機或IP地址，並允許或拒絕哪些主機/IP。
與之類似的，在Apache的httpd檔案裡有對每個目錄的允許/拒絕指定。
例如你可以把Admin Web application設定成只允許本地訪問，設定如下：
allow="127.0.0.1" deny=""/>
如果沒有給出允許主機的指定，那麼與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。
與之類似，如果沒有給出拒絕主機的指定，那麼與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。
五. 容量計劃
容量計劃是在生產環境中使用Tomcat不得不提的提高效能的另一個重要的話題。
如果你沒有對預期的網路流量下的硬體和頻寬做考慮的話那麼無論你如何做配置修改和測試都無濟於事。
這裡先對提及的容量計劃作一個簡要的定義：容量計劃是指評估硬體、作業系統和網路頻寬，
確定應用服務的服務範圍，尋求適合需求和軟體特性的軟硬體的一項活動。因此這裡所說的軟體不僅包括Tomcat，
也包括與Tomcat結合使用的任何第三方web伺服器軟體。
如果在購買軟硬體或部署系統前你對容量計劃一無所知，不知道現有的軟硬體環境能夠支撐多少的訪問量，
甚至更糟直到你已經交付並且在生產環境上部 署產品後才意識到配置有問題時再進行變更可能為時已晚。此時
只能增加硬體投入，增加硬碟容量甚至購買更好的伺服器。如果事先做了容量計劃那麼就不會搞的如 此焦頭
爛額了。
我們這裡只介紹與Tomcat相關的內容。
首先為了確定Tomcat使用機器的容量計劃，你應該從一下列表專案種著手研究和計劃：
1. 硬體
採用什麼樣的硬體體系？需要多少臺計算機？使用一個大型的，還是使用多臺小型機？每個計算機上使用幾個CPU？使用多少記憶體？
使用什麼樣的儲存 裝置，I/O的處理速度有什麼要求？怎樣維護這些計算機？不同的JVM在這些硬體上執行的效果如何
（比如IBM AIX系統只能在其設計的硬體系統上執行）
2. 網路頻寬
頻寬的使用極限是多少？web應用程式如何處理過多的請求？
3. 服務端作業系統
採用哪種作業系統作為站點伺服器最好？在確定的作業系統上使用哪個JVM最好？例如，JVM在這種系統上是否支援本地多執行緒，
對稱多處理？哪種系統可使web伺服器更快、更穩定，並且更便宜。是否支援多CPU？
4. Tomcat容量計劃
以下介紹針對Tomcat做容量計劃的步驟：
1） 量化負載。如果站點已經建立並執行，可以使用前面介紹的工具模仿使用者訪問，確定資源的需求量。
2） 針對測試結果或測試過程中進行分析。需要知道那些請求造成了負載過重或者使用過多的資源，並與其它請求做比較，
這樣就確定了系統的瓶頸所在。例如：如果servlet在查詢資料庫的步驟上耗用較長的時間，那麼就需要考慮使用緩衝池來降低響應時間。
3） 確定效能最低標準。例如，你不想讓使用者花20秒來等待結果頁面的返回，也就是說甚至在達到訪問量的極限時，使用者等待的時間也不能
超過20秒種（從點選連結 到看到返第一條返回資料）。這個時間中包含了資料庫查詢時間和檔案訪問時間。同類產品效能在不同的公司
可能有不同的標準，一般最好採取同行中的最低標準或 對這個標準做出評估。
4） 確定如何合理使用底層資源，並逐一進行測試。底層資源包括CPU、記憶體、儲存器、頻寬、作業系統、JVM等等。在各種生產環境上都按
順序進行部署和測試， 觀察是否符合需求。在測試Tomcat時儘量多采用幾種JVM，並且調整JVM使用記憶體和Tomcat執行緒池的大小進行測試。
同時為了達到資源充分合理穩 定地使用的效果，還需針對測試過程中出現的硬體系統瓶頸進行處理確定合理的資源配置。這個過程最為
複雜，而且一般由於沒有可參考的值所以只能靠理論推斷和 經驗總結。
5） 如果透過第4步的反覆測試如果達到了最優的組合，就可以在相同的生產環境上部署產品了。
此外應牢記一定要文件化你的測試過程和結果，因為此後可能還會進行測試，這樣就可以拿以前的測試結果做為參考。另外測試過程要反覆
多次進行，每次的條件可能都不一樣，因此只有記錄下來才能進行結果比較和最佳條件的選擇。
這樣我們透過測試找到了最好的組合方式，各種資源得到了合理的配置，系統的效能得到了極大的提升。
六. 附加資料
很顯然本文也很難全面而詳盡地闡述效能最佳化過程。如果你進行更多研究的話可能會把效能調優做的更好，比如Java程式的效能調整、作業系統的調整、
各種複雜環境與應用系統和其它所有與應用程式相關的東西。在這裡提供一些文中提到的一些資源、文中提到的相關內容的連結以及本文的一些參考資料。
1. Web效能測試資料及工具
1） Jmeter Wiki首頁，Jmeter為一個開源的100%Java開發的效能測試工具
2） Apache Benchmark使用說明
3） 一些Java相關測試工具的介紹，包含可以與Tomcat整合進行測試的工具
http://blog.csdn.net/wyingquan/
4） LoadRunner? 是一種預測系統行為和效能的工業標準級負載測試工具。它透過模擬資料以千萬計使用者來實施併發負載來對整個企業架構進行測試，
來幫助您更快的查詢和發現問題。
http://www.mercury.com/us/products/performance-center/loadrunner/
2. 文中介紹的相關內容的介紹
1） Apache 2.x + Tomcat 4.x做負載均衡，描述瞭如何利用jk配置叢集的負載均衡。
2） 容量計劃的制定，收集了許多有關制定web站點容量計劃的例子：
3） 評測Tomcat5負載平衡與叢集，
4） Apache與Tomcat的安裝與整合之整合篇
5） 效能測試工具之研究，介紹了效能測試工具的原理與思路
6） Java的記憶體洩漏
7） Web伺服器和應用程式伺服器有什麼區別？
8） 詳細講解效能中資料庫叢集的問題
（完）
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29500582/viewspace-1354202/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle效能調整之--DML語句效能調整Oracle
- oracle 效能調整Oracle
- oracle效能調整(1)Oracle
- oracle效能調整(2)Oracle
- ORACLE效能調整--1Oracle
- ORACLE效能調整---2Oracle
- Oracle 效能調整for HWOracle
- (zt)Oracle效能調整Oracle
- oracle效能調整2Oracle
- Oracle效能最佳化調整--調整重做機制Oracle
- 網路調整——效能調整手冊和參考
- 用於效能調整的動態效能檢視——效能調整手冊和參考
- Oracle效能調整筆記Oracle筆記
- 【效能調整】等待事件(一)事件
- 【效能調整】等待事件(二)事件
- Oracle效能調整－1（轉）Oracle
- Oracle效能調整－2（轉）Oracle
- Oracle效能調整－3（轉）Oracle
- Tomcat記憶體引數調整Tomcat記憶體
- Oracle效能調整的誤區Oracle
- Oracle高效能SQL調整OracleSQL
- oracle效能調整筆記[zt]Oracle筆記
- ORACLE之常用FAQ:效能調整Oracle
- 【效能調整】海量資料的效能設計
- Oracle 9i效能調整 [ZT]Oracle
- oracle效能優化-共享池調整Oracle優化
- 【效能調整】等待事件(九) latch原理事件
- Oracle效能調整指導綱要Oracle
- 【效能調整】系統檢視（二）
- 【效能調整】系統檢視（一）
- oracle資料庫的效能調整Oracle資料庫
- Procedure 效能檢測與調整方法
- TOMCAT記憶體溢位及大小調整Tomcat記憶體溢位
- Tomcat高階特性及效能調優Tomcat
- Tmux 速成教程：技巧和調整UX
- Oracle效能最佳化調整--調整緩衝區快取記憶體Oracle快取記憶體
- buffer cache深度分析及效能調整（五）
- buffer cache深度分析及效能調整（六）