節省JSP所產生HTML所耗費的頻寬

話說某窮苦的Web 2.0色情站…呃，是清新脫俗站，吃頻寬吃到獨孤木整天在叫。雖然用了號稱超流的服務，省掉了不少頻寬支出，不過尖峰時間頻寬用量還是很滿。猛然發現這個清新脫俗站的首頁是由某個JSP所產生，而這個JSP產生出來的HTML大小竟然在6xKB上下。這可真是驚人。像獨孤木這樣子的中年男人最怕：「冷茶、薄酒、老女人」，看來除了這三件事之外，沒有最佳化的HTML也是很恐怖的。

有一個解決這個問題的方法就是想辦法最化佳JSP中的HTML大小，把額外多餘的部份拿掉，但這個解法曠日費時。最transparent的方式，就是把JSP的輸出結果壓縮起來，交由瀏覽器去解壓縮。

這個方法的優點是省頻寬，尤其文字內容，其實壓縮率都不低。缺點則有二：(1)消耗server的CPU計算能力（2）浪費使用者瀏覽器的CPU計算能力。在Web 2.0時代，我們那裡還在乎使用者的資源被浪費？我們向來就以浪費使用者機器資源為畢生職志…呃，不是啦，是使用者的機器運算能力通常都很優質，所以缺點(2)也就沒有什麼好說的。另外，當server的CPU還在light load時，壓縮是個很好的方式。如果server的CPU也到了滿載的時候，還得再加上別的方法。希望他的diggirl可以撐到用到這個方法的時候。

對於要壓縮JSP的內容，Java的Servlet/JSP架構提供了十分transparent的方法，也就是filter。每個Web Application都會有一個filter chain，在這個chain中，可以有多個filter，而所有的request/response都會經過這個filter chain中的filter。你可以在filter裡對request或response做加工。像我們很習慣做個PermissionFilter，在裡頭檢查request是否具備適合的存取權限。

要在既有的情況下對JSP做壓縮，最簡單的方式就是利用filter來做。壓縮也是一種加工，我們只要在filter裡對response的stream做壓縮加工即可。

這件事有幾個要點：(1)從request的header裡取出Accept-Encoding，看看它支不支援x-gzip或gzip，就算沒有Accept-Encoding ，也強迫塞gzip給它，反正IE和Firefox一定支援(2)設定response的Content-Encoding header，把它設成x-gzip或gzip(3)建立一個繼承HttpServletResponseWrapper的類別，這時候我們會套用Decorator這個設計模式，把HttpServletResponseWrapper衍生類別的instance傳入filter chain的chain.doFilter()。

參考這篇文章也是可以的：

Two Servlet Filters Every Web Application Should Have

http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html

Posted at 12:14上午 二月 12, 2007 by Chien-Hsing Wang in Java  |  迴響[5]