使用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;
  3. public void doFilter(ServletRequest req, ServletResponse res,
  4. FilterChain chain) throws IOException, ServletException {
  5. HttpServletResponse response = (HttpServletResponse) res;
  6. // set the provided HTTP response parameters
  7. for (Enumeration e = fc.getInitParameterNames(); e.hasMoreElements();) {
  8. String headerName = (String) e.nextElement();
  9. response.addHeader(headerName, fc.getInitParameter(headerName));
  10. }
  11. // pass the request/response on
  12. chain.doFilter(req, response);
  13. }
  14. public void init(FilterConfig filterConfig) {
  15. this.fc = filterConfig;
  16. }
  17. public void destroy() {
  18. this.fc = null;
  19. }
  20. }

web.xml里的巧妙配置:

  1. <filter>
  2. <filter-name>NoCache</filter-name>
  3. <filter-class>apis.server.common.util.ResponseHeaderFilter</filter-class>
  4. <init-param>
  5. <param-name>Cache-Control</param-name>
  6. <param-value>no-cache, must-revalidate</param-value>
  7. </init-param>
  8. </filter>
  9. <filter>
  10. <filter-name>CacheForWeek</filter-name>
  11. <filter-class>apis.server.common.util.ResponseHeaderFilter</filter-class>
  12. <init-param>
  13. <param-name>Cache-Control</param-name>
  14. <param-value>max-age=604800, public</param-value>
  15. </init-param>
  16. </filter>
  17. <filter-mapping>
  18. <filter-name>NoCache</filter-name>
  19. <url-pattern>*.do</url-pattern>
  20. </filter-mapping>
  21. <filter-mapping>
  22. <filter-name>CacheForWeek</filter-name>
  23. <url-pattern>/images/*</url-pattern>
  24. </filter-mapping>
  25. <filter-mapping>
  26. <filter-name>CacheForWeek</filter-name>
  27. <url-pattern>/img/*</url-pattern>
  28. </filter-mapping>
  29. <filter-mapping>
  30. <filter-name>CacheForWeek</filter-name>
  31. <url-pattern>/icons/*</url-pattern>
  32. </filter-mapping>
  33. <filter-mapping>
  34. <filter-name>CacheForWeek</filter-name>
  35. <url-pattern>/ext/*</url-pattern>
  36. </filter-mapping>
  37. <filter-mapping>
  38. <filter-name>CacheForWeek</filter-name>
  39. <url-pattern>*.js</url-pattern>
  40. </filter-mapping>
  41. <filter-mapping>
  42. <filter-name>CacheForWeek</filter-name>
  43. <url-pattern>*.css</url-pattern>
  44. </filter-mapping>

(插入一段:在探测这些性能问题的时候,我使用的是一个Firebug的插件,也就是Firefox插件的插件-YSlow,好像是Yahoo的,结合Firebug里XHR的Net这块做Profiling,效果很不错,很容易就知道瓶颈)
还有一个gzip的办法,就是在服务器压缩内容,再传给浏览器。现在主流的浏览器都支持gzip压缩,而且这些html和js文本压缩起来很厉害,基本上可以有40%的压缩率。办法在servel.xml的注释里也有写,就是在Connector元素里加上
compression=”on”
compressionMinSize=”2048″
noCompressionUserAgents=”gozilla,traviata”
compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain”
以上的内容大部分都是Google得来,我自己做了一下整理

Leave a Reply

Your email address will not be published.