簡單地說,這是假的。要仔細講的話,在 Tomcat 3 的年代是有一些真實成份在。不過以現今使用的 5.5.x 以及 6.0.x 來說,實在沒有必要因為單純效能的理由來使用 httpd。Tomcat 現在支援 native / APR 的 connector,使用與 httpd 相同的 native library(Apache Protable Runtime APR)來處理低階 I/O,因此可以達到與 httpd 差不多的效能。當處理靜態內容時,Tomcat 是比 httpd 多一小點兒的負荷量,但實在太小了以至於在 production system 上很難注意到差異。
如果你研究 httpd 與 Tomcat 的效能議題,你會找到各種覆載與效能的 benchmark,結果也不盡相同。一個常被引用的結果證明 Tomcat 的純 Java connector 始終比 httpd 快。
這個異常的結果剛好與期待相反:httpd 應該比 Tomcat 的 pure Java connector 快上很多才對。這可能是所使用的檔案大小導致的結果。Tomcat 會預設把小的靜態檔案 cache 在記憶體中,這可以提供顯著的效能提昇。httpd 在預設情況下沒有作這件事。這很明確地證實 benchmark 的定義會影響結果。
Christopher Schultz(Tomcat mailing list 的常客)以一個較大範圍的檔案大小進行這個測試(譯註:連結已經失效),在我看來這個測試比較好一點。結果顯示在下面這張圖表中:
這更符合預期了,不過有一些有趣的重點要注意:
- Apache httpd 與 Coyote APR / native 的效能表現在同一個水準
- Coyote NIO 只落後 httpd 與 Coyote APR / native 一點
- 看起來似乎 sendfile 的效益有一個極限在。有可能是硬體限制,不過值得進一步關注。我已經把這個加到我的待辦事項中。
- 對於小於 10KB 的檔案,Tomcat 有顯著的效能提昇。
- httpd 與 Coyote APR / native 有差不多的效能
- Coyote NIO 比 Coyote APR / native 差一點(在用 SSL 的情況下會差更多)
- Coyote BIO 通常是最差的。
另外要注意的是:Tomcat 中沒有「讓它跑的比較快」的魔法設定。如果你的 application 花 15 秒來產生一個 request,Tomcat 沒辦法改進些甚嘛。你必須監控你的 application 以了解為甚麼 request 會花這麼久的時間,然後適當地調整你的程式碼。
雖然單純從效能觀點,沒有什麼好理由去用 httpd,不過還是有其他論點支持 Tomcat 應該搭配 httpd。最常見的原因是為兩個以上的 Tomcat 提供 load balance。httpd 並不是唯一的選擇,也可以用硬體的 load balance 或是其他 reverse proxy,不過系統管理者仍然會選擇他們已經很熟的 httpd。我未來會寫更多用 httpd 當 load balancer 的文章。
有需要支援 Java 以外的技術,也是 Tomcat 與 httpd 一起使用的原因。Tomcat 可以支援 PHP 與 Perl,不過在 httpd 當中支援度較好。因此,對於需要混合技術的網站,httpd 可以用來當前端的 web server,將 request 導向 mod_php、mod_fastcgi、mod_proxy_http(給 Tomcat)或是其他的 module。
另一個這樣用的原因:httpd 可以將 Windows 的身份認證整合進來。有 Tomcat 整合 Window 身份認證的方式,在更廣泛地使用之後,這讓是不是用 httpd 變得不那麼重要。然後,這仍是讓 httpd 搭配 Tomcat 使用的一個常見原因。
總而言之,有充分的理由讓 httpd 搭配 Tomcat 使用,不過靜態內容的效能並不是其中之一。如果你僅僅是為了加強靜態內容的效能而用 httpd,那我建議你看一下給 Apache Tomcat 使用的 Coyote APR / native connector。
可能是錯字:
回覆刪除「如果你的 application 花 15 秒來產生一個 request,Tomcat 沒辦法改進些『甚嘛』。」
另外想問,有 jetty 時為啥要用 tomcat?
囧... Win7 上頭得打「甚嘛」才會出現「什麼」,結果回到 XP 會常常改不過來。
回覆刪除至於為什麼有 Jetty 的時候還要用 Tomcat... 說真的我不知道...
這有點像是為甚麼有了 Java 還要用 C... [被拖走]