使用Cache-Control和gzip提升tomcat应用性能(整理)

    这个其实应该是常识，只不过以前做的J2EE应用大部分是内网里跑的东西，所以性能上没什么问题。这次APIS由于有在外面用的可能，加上使用了一些比较大的javascript框架(Ext)，所以性能问题瞬间窜了上来。
以前做的J2EE应用没有使用上达500K的框架，最多就是几十K的Prototype，所以没什么问题。一个页面一般也就几十K最多了。但这次还在开发中的APIS，由于还在用debug版本的库，所以单单Ext就膨胀到了一个多M，加上不知道是Struts还是Tomcat默认写入Response的cache-control: no cache，在远程用起来就很慢，一般一个页面需要十多秒种甚至更久，实在无法忍受。前几天集中解决了问题。
    首先是Cache-Control的问题，Google了好一阵，没有什么直接配置的方法，只好自己抄了一个一个Filter，通过和web.xml里配置的配合勉强凑合着用。一般就是对*.do实施no-cache政策，其他需要缓存的img, js文件，统统加上长达两周的缓存期限。ETag实在不会用，就先用这个缓存策略吧。

Filter的代码：

1. public class ResponseHeaderFilter implements Filter {
2.     FilterConfig fc; 
4.     public void doFilter(ServletRequest req, ServletResponse res,
5.             FilterChain chain) throws IOException, ServletException {
6.         HttpServletResponse response = (HttpServletResponse) res;
7.         // set the provided HTTP response parameters
8.         for (Enumeration e = fc.getInitParameterNames(); e.hasMoreElements();) {
9.             String headerName = (String) e.nextElement();
10.             response.addHeader(headerName, fc.getInitParameter(headerName));
11.         }
12.         // pass the request/response on
13.         chain.doFilter(req, response);
14.     } 
16.     public void init(FilterConfig filterConfig) {
17.         this.fc = filterConfig;
18.     } 
20.     public void destroy() {