最近正好要用到這些內容，因此就找了一篇比較有分量的文章，思來想去，還是嘗試寫一下譯文吧。其實LZ的英語是非常爛的（四級沒過的LZ眼淚掉下來），因此這篇文章翻譯的水平LZ自己也不敢恭維。各位猿友大致參考一下即可，其中【】符號是LZ的標注，（）內的是原文。如果各位有哪裡實在看不明白的話，可能是LZ翻譯的問題，各位猿友可以去看原文的內容，地址：http://people.apache.org/~mturk/docs/article/ftwai.html。
倘若你想實現最大的性能和穩定性的話，那麼在web服務器後運行tomcat集群是必經之路，這篇文章就是用來描述完成這件事的最佳實踐。
一些人可能會問“為什麼要在tomcat前面放置一個web server？”由於最近的JVM技術以及tomcat核心本身的原因，單個tomcat的性能已經非常接近於本地的web服務器，甚至當發送靜態文本時，tomcat也只比當前的Apache2web服務器慢10%。因此答案就是：擴展性。
tomcat通過給每個客戶端連接分配獨立的線程，可以服務許多用戶的並發訪問。盡管這樣tomcat可以做的很好，但是當並發連接數上升的時候，將會出現一些問題。系統為了管理這些線程所花費的時間會降低整體的性能，JVM也將花費更多的時間管理和切換這些線程，然後才能真正的對客戶的請求做一些具體的工作。
此外，當應用直接運行在tomcat上的時候，連通性（connectivity）也有不少嚴重的問題。一個典型的應用可能會處理用戶數據、訪問數據庫或者做一些計算再將結果返回給客戶端。所有的這些都是一些耗時的工作，但是為了讓用戶感覺這是一個可以正常運行的應用程序，大多數時候必須在半秒內（500ms）就完成。如果應用的響應時間為10ms，那麼在你的客戶抱怨之前，你的應用最多只能同時服務50個並發用戶【這句話有點別扭，0.0，但大致意思是理解的】。那麼為了支持更多的用戶你該怎麼做呢？最簡單的辦法就是買一個更快的硬件，增加更多的CPU或者更多的箱子（boxes）【boxes？箱子？】。兩個雙路箱子一般比一個四路的便宜，因此添加更多的箱子一般比買一個服務器更加省錢【貌似這個箱子可以替代服務器，到底是什麼東西，有英語好的給翻譯一下】。
降低tomcat負載的第一件事就是使用web server處理靜態文本，就像下圖一樣。
上圖給出了最簡單的可行的配置方案。web server用來傳送靜態文本，而tomcat只處理具體的工作，也就是應用服務。大多數情況下，這就可以滿足你了。如果用一個四路的箱子【又是箱子，0.0】，並且應用的響應時間為10ms的話，那麼你將能同時服務200個用戶，也就是說，一天可以支持350萬的訪問量【不知道350萬這個數字怎麼算出來的，用200*60*60*24不是350萬，0.0】，這已經是一個比較可觀的數字了。
在以上這種程度負載的情況下，你或許不太需要將web server放在tomcat之前。但是還有第二個原因讓你這麼做，那就是這樣創建了一個控制區（demilitarized zone）。將web server放在一個主機上等於在公司的私有網絡與互聯網或者是其它的外部公共網絡之間插入了一個隔離區（neutral zone），這可以讓tomcat上的應用安全的訪問其它的私有資源，也可以訪問公司的私有數據。
除了擁有控制區和可以安全的訪問私有網絡，還有一些其它的原因，比如可以滿足自定義授權的需要。
如果有更多的負載需要承載的話，那麼你將不得不添加更多的tomcat應用服務器，這可能是因為客戶端的負載已經無法被一個簡單的箱子【靠，到現在還沒猜出來箱子是什麼】處理，也可能是因為當某一個節點宕機時，你需要一種故障恢復的機制。
部署一個包含了多個tomcat應用服務器的架構，需要在web server和tomcat之間加入一個負載均衡器。在apache1.3、apache2.0和IIS中，你可以使用Jakarta Tomcat Connector，因為它提供負載均衡和黏性session機制。在將來的apache2.1/2.2中，可以使用advanced mod_proxy_balancer，它是一個新設計的模塊並整合在apache httpd的核心當中。
當決定tomcat服務器數量時，你需要滿足客戶端負載，首要的任務就是決定應用的平均響應時間。正如之前所說，為了滿足用戶體驗，應用不得不在半秒內響應用戶。客戶端浏覽器收到的內容通常會觸發多次對web server的請求，比如圖片。web頁面通常由html和圖片數據構成，所以客戶端會分發一系列的請求，而獲得這些所花費的總的處理和傳送時間就是平均響應時間。為了不超過tomcat的極限，你應該限制並發請求數不高於“200/CPU”。
因此，我們可以從一個簡單的公式計算出一個物理箱子【這個箱子到底是什麼，0.0】能夠處理的最大的並發連接數：
並發請求數 = max(500/平均響應時間,200) * CPU個數
另外一件你需要考慮的事，就是web server和tomcat實例之間的網絡吞吐量。這裡介紹一個新的概念，叫做平均響應大小，這是指一個web頁面傳送給用戶的所有的字節大小。對於一個標准的“8位/字節”的100Mbps網卡，理論上最大的吞吐量為12.5Mbytes。
並發連接數 = 12500/平均響應大小
對於20KB的平均響應大小來說，最大可以支持625的並發請求數。如果你需要承載更大的負載，那麼可以增加更多的卡或者使用更快的1Gbps的硬件。
上面的公式教你對於一定數量的並發請求，如何大概估算tomcat、箱子和CPU的數量。如果你接觸不到具體的硬件就要進行配置，你可以在一個測試平台上測試平均響應時間，然後比較測試平台與硬件提供商的SPECmarks，這樣你可以獲得一個比較接近的數值。
文章就先翻譯到這裡吧，剩下的有時間再來翻譯，鍛煉下自己的有道水平。總的來說，LZ是大致看懂了這篇文章，但是仍舊有些不明白的地方，比如那個box，也就是箱子，到底是指的什麼。LZ覺得這個box絕對不應該簡單的翻譯成箱子，但是LZ實在想不到是什麼玩意，所以就只能暫時這麼寫了。希望有高人路過的話，回答一下這個箱子到底是什麼。
LZ看到這兩幅圖的時候笑跪了，您呢，0.0。
作者：zuoxiaolong（左潇龍）
出處：http://www.cnblogs.com/zuoxiaolong
