tomcat优化之Http请求压缩

HTTP 压缩可以大大提高浏览网站的速度，它的原理是，在客户端请求网页后，从服务器端将网页文件压缩，再下载到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML ,CSS,Javascript , Text ，它可以节省40%左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP , JSP , ASP , Servlet,SHTML等输出的网页也能进行压缩，压缩效率惊人。

下面对同一个请求进行测试。

这是压缩前的请求：

这是压缩后的请求：

两次请求都是在禁用缓存的情况下访问项目上的个人工作台页面，可以看到开启压缩之后，请求的资源被大幅减少了，提升非常明显。 

开启Gzip

开启tomcat的Gzip只需要找到 tomcat/conf 路径下面的server.xml文件，在Connector内添加如下红色部分的4个参数：

1.   compression这个参数指定开启Gzip压缩，默认为off；

2.   compressionMinSize，当被压缩对象的大小>=该值时才会被压缩，这里默认为2KB，对资源压缩时会消耗一定的cpu性能，对2KB以上的资源才进行压缩是官方给出的建议，实际使用时可以根据需求在响应时间和cpu性能之间做取舍；

3.   noCompressionUserAgents，指定以下浏览器不启用压缩；

4.   compressableMimeType，指定对以下类型的资源文件进行压缩。

 

Gzip无法压缩48k以上的资源？

提升Tomcat性能方法有很多种，使用NIO Connector和启用gzip压缩是其中两种。

NIO：Java New IO，使用了多路复用的技术，无疑要比普通的IO socket要高效。

gzip：对需要传输到前台的内容首先在内存中进行gzip压缩，这样可以大大的减少网络带宽占用。前提是前台的Accept-Encoding允许gzip。

但是，当同时配置了这两个时，会发现大于48KB的文件并没有进行压缩。

经查Tomcat源码，发现org.apache.catalina.servlets.DefaultServlet中：

 

此处的sendfileSize = 48*1024，默认值为48KB，可以发现，当文件大小大于48KB时，Tomcat并未马上将内容写回到output中，而是把文件的路径记录下来。

并在Http11Processor的process方法的最后一部分，把文件内容以FileChannel的形式写回到前台，不需要先把文件内容先读到用户内存->压缩->写回socket内核内存。

这种NIO底层读写channel的形式避免了读取到用户内存的开销，也可以提升性能。

目前，尚不清楚使用NIO快，还是gzip较快，有待测试。

如果在使用NIO的同时还一定要用gzip，可以关闭NIO Connector的useSendFile选项。