http://blog.itpub.net/29500582/viewspace-1354202/
一. 引言
性能測試與分析是軟件開發過程中介於架構和調整的一個廣泛並比較不容易理解的領域，更是一項較爲複雜的活動。
就像下棋遊戲一樣，有效的性能測試 和分析只能在一個良好的計劃策略和具備了對不可預料事件的處理能力的條件下順
利地完成。一個下棋高手贏得比賽靠的不僅僅是對遊戲規則的認識，更是靠他的自 己的能力和不斷地專注於分析自己對
手的實力來更加有效地利用和發揮規則的作用。同樣一個優秀的性能測試和分析人員將要面對的是來自一個全新的應用
程序和環 境下帶來的整個項目的挑戰。本文中作者結合自己的使用經驗和參考文檔，對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壓力測試工具
http://www.softwareqatest.com/qatweb1.html#LOAD
這裏我們所使用的工具要支持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 http://tomcathost:8080/examples/date/date.jsp
This is ApacheBench, Version 2.0.36 <$Revision: 1.1 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
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<size>
JVM初始化堆的大小
-Xmx<size>
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
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="80" minProcessors="5" maxProcessors="75" 】
enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" useURIValidationHack="false" disableUploadTimeout="true" />
Tomcat5
<Connector port="80" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443"
acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true"/>
除非你需要連接到站點的每個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（可訪問http://oss.software.ibm.com/pub/jikes 獲得更多的信息），接着需要在環
境變量中設置JIKESPATH包含系統運行時所需的JAR文件。裝好Jikes以後還需要設置讓JSP編譯servlet使
用Jikes，需要修改web.xml文件中jspCompilerPlugin的值：
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>jspCompilerPlugin</param-name>
<param-value>
org.apache.jasper.compiler.JikesJavaCompiler
</param-value>
</init-param>
<init-param>
<!-- <param-name>
org.apache.catalina.jsp_classpath
</param-name> -->
<param-name>classpath</param-name>
<param-value>
/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
/usr/local/lib/java/servletapi/servlet.ja
r</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
在Tomcat 4.1（或更高版本），JSP的編譯由包含在Tomcat裏面的Ant程序控制器直接執行。這聽起
來有一點點奇怪，但這正是Ant有意爲之的一部分，有一 個API文檔指導開發者在沒有啓動一個新的JVM
的情況下，使用Ant。這是使用Ant進行Java開發的一大優勢。另外，這也意味着你現在能夠在Ant 中使
用任何javac支持的編譯方式，這裏有一個關於Apache Ant使用手冊的javac page列表。使用起來是容
易的，因爲你只需要在 元素中定義一個名字叫“compiler”，並且在value中有一個支持編譯的編譯器名
字，示例如下：
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>compiler</param-name>
<param-value>jikes</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
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頁面的功能。例如，你可以在瀏覽器地址欄中輸入
http://localhost:8080/examples/jsp/dates/date.jsp?jsp_precompile=true ，
這樣Tomcat就會編譯data.jsp而不是執行它。此舉唾手可得，不失爲一種檢驗頁面正確性的捷徑。
4. 其它
前面我們提到過操作系統通過一些限制手段來防止惡意的服務攻擊，
同樣Tomcat也提供了防止惡意攻擊或禁止某些機器訪問的設置。
Tomcat提供了兩個參數供你配置：RemoteHostValve 和RemoteAddrValve。
通過配置這兩個參數，可以讓你過濾來自請求的主機或IP地址，並允許或拒絕哪些主機/IP。
與之類似的，在Apache的httpd文件裏有對每個目錄的允許/拒絕指定。
例如你可以把Admin Web application設置成只允許本地訪問，設置如下：
<Context path="/path/to/secret_files" ...>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1" deny=""/>
</Context>
如果沒有給出允許主機的指定，那麼與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。
與之類似，如果沒有給出拒絕主機的指定，那麼與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。
五. 容量計劃
容量計劃是在生產環境中使用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開發的性能測試工具
http://wiki.apache.org/jakarta-jmeter/
2） Apache Benchmark使用說明
http://httpd.apache.org/docs-2.0/programs/ab.html
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配置集羣的負載均衡。
http://raibledesigns.com/tomcat/index.html
2） 容量計劃的制定，收集了許多有關制定web站點容量計劃的例子：
http://www.capacityplanning.com/
3） 評測Tomcat5負載平衡與集羣，
http://www.javaresearch.org/article/showarticle.jsp?column=556&thread=19777
4） Apache與Tomcat的安裝與整合之整合篇
http://www.javaresearch.org/article/showarticle.jsp?column=23&thread=18139
5） 性能測試工具之研究，介紹了性能測試工具的原理與思路
http://www.51testing.com/emagzine/no2_2.htm
6） Java的內存泄漏
http://www.matrix.org.cn/resource/article/409.html
7） Web服務器和應用程序服務器有什麼區別？
http://www.matrix.org.cn/resource/article/1429.html
8） 詳細講解性能中數據庫集羣的問題
http://www.theserverside.com/articles/article.tss?l=db_break