測量web服務器的性能是一項讓人感到畏縮的任務，但是我們在這裏將給出一些需要注意的地方 並且指點你瞭解其中更多的細節性的內容。它不像一些簡單的任務，如測量CPU的速率或者是測量程序佔用CPU的比例，web服務器的性能優化中包括許調整 許多變量來達到目標。許多的測量策略中都包含了一個看似簡單的瀏覽實際上是在向服務器發送大量的請求，我們稱之爲客戶端的程序，來測量響應時間。客戶端和 服務器端是在同一臺機器上嗎？服務器在測試的時候還運行着其它的什麼程序嗎？客戶端和服務器端的通訊是通過局域網，100baseT，10baseT還是 使用調制解調器？客戶端是否一直重複請求相同的頁面，還是隨機地訪問不同的頁面？（這些影響到了服務緩存的性能）客戶端發送請求的有規律的還是突發的？你 是在最終的配置環境下運行服務的還是在調試的配置環境下運行服務的？客戶端請求中包含圖片還是隻有HTML頁面？是否有請求是通過servlets和 JSP的，CGI程序，服務端包含（Server-Side Includes ，SSI是一個可以讓你使用動態HTML文件的技術）？所有這些都將是我們要關心的，並且幾乎我們不可能精確地把所有的問題都清楚地列出來。
二 tomcat調整
在 Tomcat和應用程序進行了壓力測試後，如果您對應用程序的性能結果不太滿意，就可以採取一些性能調整措施了，當然了前提是應用程序沒有問題，我們這裏只講Tomcat的調整。由於Tomcat的運行依賴於JVM，所以在這裏我們把Tomcat的調整可以分爲兩類來詳細描述：
外部環境調整
調整非Tomcat組件，例如Tomcat運行的操作系統和運行Tomcat的java虛擬機。
自身調整
修改Tomcat自身的參數，調整Tomcat配置文件中的參數。
可以給Java虛擬機設置使用的內存，但是如果你的選擇不對的話，虛擬機不會補償。可通過命令行的方式改變虛擬機使用內存的大小。如下表所示有兩個參數用來設置虛擬機使用內存的大小。
|
參數 |
描述 |
|
-Xms<size> |
JVM初始化堆的大小 |
|
-Xmx<size> |
JVM堆的最大值 |
這兩個值的大小一般根據需要進行設置。初始化堆的大小執行了虛擬機在啓動時向系統申請的內存的大小。一般而言，這個參數不重要。但是有的應用程序在大負載 的情況下會急劇地佔用更多的內存，此時這個參數就是顯得非常重要，如果虛擬機啓動時設置使用的內存比較小而在這種情況下有許多對象進行初始化，虛擬機就必 須重複地增加內存來滿足使用。由於這種原因，我們一般把-Xms和-Xmx設爲一樣大，而堆的最大值受限於系統使用的物理內存。一般使用數據量較大的應用 程序會使用持久對象，內存使用有可能迅速地增長。當應用程序需要的內存超出堆的最大值時虛擬機就會提示內存溢出，並且導致應用服務崩潰。因此一般建議堆的 最大值設置爲可用內存的最大值的80%。
另外需要考慮的是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站點的流量都是一樣的，因此沒有一刀切的方案來確定線程數的值。