二. 測量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.壓力測試工具介紹
三. 外部環境的調整在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下，在文件/bin/catalina.bat，Unix下，在文件/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