Tomcat性能調整完整教程

Tomcat性能調整完整教程

發表於：2007-07-13 來源： 做者： 點擊數：526  標籤：

一. 引言 性能測試與分析是軟件 開發 過程當中介於架構和調整的一個普遍並比較不容易理解的領域，更是一項較爲複雜的活動。就像下棋 遊戲 同樣，有效的性能測試和分析只能在一個良好的計劃策略和具有了對不可預料事件的處理能力的條件下順利地完成。一個下棋高

一. 引言

　　性能測試與分析是軟件開發過程當中介於架構和調整的一個普遍並比較不容易理解的領域，更是一項較爲複雜的活動。就像下棋遊戲同樣，有效的性能測試和分析只能在一個良好的計劃策略和具有了對不可預料事件的處理能力的條件下順利地完成。一個下棋高手贏得比賽靠的不只僅是對遊戲規則的認識，更是靠他的本身的能力和不斷地專一於分析本身對手的實力來更加有效地利用和發揮規則的做用。一樣一個優秀的性能測試和分析人員將要面對的是來自一個全新的應用程序和環境下帶來的整個項目的挑戰。本文中做者結合本身的使用經驗和參考文檔，對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® 是一種預測系統行爲和性能的工業標準級負載測試工具。它經過模擬數據以千萬計用戶來實施併發負載來對整個企業架構進行測試，來幫助您更快的查找和發現問題。 
　　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.ltesting.net/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