启用 IHS GZip 压缩提高网络 IO 性能

          默认安装配置下 IHS 并未启用 GZip 压缩选项，我们也可以通过 IHS 本身的 httpd.conf 文件配置和通过 HttpWatch、Fiddler 等工具查看前端 HTTP 响应内容来确认 IHS GZip 压缩是否启用、正确。一般情况下应该考虑启用 Web 服务器上 GZip 压缩，这样可以有效缩短客户端到 Web 服务器间的网络 RTT 指标，尤其是在中低速网络情况下；同时对于广泛使用的以文本类型 XML 数据为主的 Ajax 应用的数据推送，这种压缩也非常有效。

 

          IHS 中启用 GZip 压缩功能超级简单，只需要在 httpd.conf 配置文件最后添加如下内容，就可以启用 GZip压缩了。httpd.conf 位于 IHS_HOME/conf 中，修改前应做好备份。

 

LoadModule deflate_module modules/mod_deflate.so

<Location />
	# Insert filter
	SetOutputFilter DEFLATE

	# Netscape 4.x has some problems...
	BrowserMatch ^Mozilla/4 gzip-only-text/html

	# Netscape 4.06-4.08 have some more problems
	BrowserMatch ^Mozilla/4\.0[678] no-gzip

	# MSIE masquerades as Netscape, but it is fine
	BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

	# Don't compress images
	SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

	# Make sure proxies don't deliver the wrong content
	# Header append Vary User-Agent env=!dont-vary
</Location> 

DeflateCompressionLevel 9
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%h %l %u %t %r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog logs/deflate_log deflate

 

          注意配置中有几点要清楚：

 

1. 对于 Mozilla 特定浏览器只压缩“text/html”Content-Type 的响应内容启用压缩；
2. 对于 Mozilla 特定浏览器不启用压缩；
3. 对于 gif、jpg/jpeg 和 png 类型的资源文件不启用压缩，因为它们本事是压缩存储格式；
4. 对于上述配置中注释的“Header append Vary User-Agent env=!dont-vary”，表示在存在代理时在 HTTP 头中添加“User-Agent”内容。如果需要该功能，则在取消该配置注释的同时，应安装并启用 Header 插件：“LoadModule headers_module modules/mod_headers.so”。
5. 通过“DeflateCompressionLevel”配置了压缩比，deflate 插件使用 Zlib 来压缩 HTTP 请求及响应流，压缩比可以配置为 1（最小压缩比）至 9（最大压缩比），需要说明的是压缩比越高对 Web 服务器主机的 CPU 资源开销越大，如果此时 CPU 资源存在瓶颈的话响应时间也会相应延长。
6. 对输入输出（响应请求）内容字节长度写入日志。

          关于 deflate_module 和 mod_headers 插件的详细配置说明，可以参见 Apache HTTP Server 的官方说明：

 

Apache Module mod_deflate

Apache Module mod_headers

 

          下在面的对比内容说明了，某个业务用例在一定量的并发用户负载场景中，在 IHS GZip 压缩启用前后的网络发送量差异，可见通过压缩能够有效的提高网络 IO 吞吐性能：

 

 

          从上面的对比数据可以看到，当前场景中在启用 GZip 压缩后 IHS 主机的网络 Sent MB/s 指标从 5MB/s 减少到 2.5MB/s，减少到原来的 50%。

 

          这种优化效果从客户前端也能够看到，对于某一个单用户的 Ajax 较大数据量的查询请求，从度量结果可以明显看到通过压缩减少网络传输数据量所带来的响应时间提高。

 

 

          从上面的数据可以看到，在启用 GZip 压缩后，IHS 主机的网络 Receive 时间指标从 17ms 减少到 4ms，降低到原来的 23.5%；同时网络流量也从 29804 字节减少到 1499 字节，减少到原来的 5%。而且整体响应时间相对未启用 GZip 压缩时仅增长了 89ms，这一小段时间消耗在 IHS 压缩上（CPU clock）。

 

          最后需要说明的是，这种通过压缩来提高网络 IO 的方法并不是对 IHS 完全没有影响的，压缩算法需要额外的 CPU 时间（CPU clock）来进行压缩运算，下面的数据可以说明这一点，从现在 IHS 主机的 CPU 资源来看，在启用 GZip 压缩前 CPU 利用率平均为 4.5%，启用 GZip 压缩后 CPU 利用率平均为 12.88%。但是，很明显 IHS 主机 CPU 资源依旧很充足，用这一点空闲的 CPU 资源来提升网络 IO 性能还是很值得的。当然，你也可以通过 mod_deflate 插件的“DeflateCompressionLevel”指令来配置 Zlib 的压缩比，在 CPU 利用率、压缩效果、延时（响应）时间上找到平衡点。

 

 

浑浑沉沉的一天又结束了，睡觉～～

 

作者：lzy.je
出处：http://lzy.iteye.com
本文版权归作者所有，只允许以摘要和完整全文两种形式转载，不允许对文字进行裁剪。未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

 

 

评论

1 楼 曾经de迷茫 2009-08-21  

不错.有机会实验一下!