关于Ext的Js太大的问题研究解决

    久别大家一年了，其实这一年我从简单实现了一个Yui-Ext0.33项目后，基本没有在Ajax表现层花太多的时间，而是转向研究Jbpm和WebService在项目中的应用，而且大半年前Ext推出1.0版本，感觉在项目中升级使用还不够成熟，所以在项目中继续应用小巧的0.33版，基本满足需要。

     由于现在项目越来越大，而且Ext2已经推出，界面实在充满诱惑，相信商业化的Ext2将更适合项目开发，所以现在对Ext2一些关键问题进行研究，首当其冲要解决的就是ext-all.js(512K)太大的问题。

     针对js包太大的问题，有两个现在比较流行的解决方案：
     1. 使用jsbuild等工具把需要调用的js重新包装，此方法的缺点是Ext用的最多的是form和grid等控件，删减后包容量减少不明显，而且我是打包了几次失败，就没耐心了，当然，要做到最好调优，这个方案是要考虑的，基本方法就是页面调用核心的ext-core.js，然后再把页面要用的包自己包装。

     2. 使用gzip在服务器端牺牲一点cpu资源进行压缩，有效减低传输流量，由浏览器解压处理后执行。这个解决方案另我眼前一亮，其实也不是什么新东西，2005年的老东西了，只是当时没有想到js会如此庞大，但现在老技术还是很实用的。下面将重点研究这个解决方案。

     第一步，在web.xml增加一个gzipfilter，不用自己写，有现成的，到地址：http://sourceforge.net/projects/filterlib下载，新建一个测试项目，最简单就在index.jsp直接调用ext-all.js，把tk-filters.jar拷贝到项目的lib目录，然后在web.xml加入：

	<filter>
		<filter-name>CompressingFilter</filter-name>
		<filter-class>
			com.tacitknowledge.filters.gzipfilter.GZIPFilter
		</filter-class>	
	</filter>
         <!-- 这里按自己许多针对不同文件进行filter-mapping配置，比如*.css -->
	<filter-mapping>
		<filter-name>CompressingFilter</filter-name>
		<url-pattern>*.js</url-pattern>                  
	</filter-mapping>

     第二步，调试，调试js现在发现最好的工具应该是FireFox+firebug(插件),FireFox我用1.5版本，调试足够了，我使用Weblogic作调试服务器，tomcat也可以，但我的tomcat在server.xml直接配置gzip压缩功能，所以用weblogic免得测试不出来。启动项目后，用Firefox打开index.jsp页面，页面调出后可能会有脚本错误，但可以不管，关键看文件的大小，打开工具->firebug->open firebug,寻找net项，即可看到调用的ext-all.js的压缩效果，如附图的比较，效果不错吧，512K => 137K，如果发现js压缩没效果，注意打开工具->清除私隐数据，清掉可能存在的cache，再刷新页面重试。

     第三步，压力测试，我使用loadrunner7.8测试，简单实用，没有8.0以上版本的华丽和慢。使用1000个进程测试，发现了意外的结果(见附图)，在本机测试，不用gzip压缩只用了36秒，而使用gzip压缩后则是1分49秒，流量在压缩后从1,315,914,600降到313，125，680，流量随着文件的压缩而减少，效果也很明显，查其原因，应该是因为压缩和解压对服务器和浏览器的资源消耗，而且是在本机测试，本机排除了带宽的影响，所以压缩前性能反而高了。

     由于我研究的时间不长，在压力测试方面还没在实际项目中测试，不能一概而论，初步分析，如果是局域网项目，带宽不受限制，不使用压缩性能会好点，而对于互联网环境则要考虑压缩方案，也希望有兴趣的开发者共同研究一下这个解决方案在实际项目中的可行性，希望大家讨论。

用servlet container加载gzip filter压缩？真是太疯狂了...
在前面加个HTTP Server，开启gzip，比java写的filter性能不知道要好NNN倍...

嗯， 主要是应用架构一般会设在HTTP服务之后，所谓的大型项目一般还要加层防火墙，速度可想而知。另外您这样做Filter的设计，还要在HTTP层配制下JS的访问策略，不如直接用轻量级的HTTP服务做gzip与CACHE， 一是避免不必要的网络传 输， 另一方面避免不必要的IO操作。2G奔四可以一秒响应三千并发，自己写的再轻量级的WEB服务可以跑的更快。

如果一定要用tomcat，也可以先用gzip压了，然后把header改一下就行了，这样不需要动态压缩。

    对于业务系统，基本都是jsp页面，在前端再加一个http server似乎意义不大，经过测试，使用filter动态压缩js消耗cpu资源，反而性能减低，filter、apache和tomcat的三种压缩方案，网上也没有对性能做仔细测试的，大家都关注压缩的结果，而没有认真考虑性能是否真的提高。

     如楼上所说，先用gzip压了，然后把header改一下这个方法不错，以下地址有例子：
     http://www.iteye.com/topic/37176 <<关于JavaScript的gzip静态压缩方法 >>

    以上例子先对ext-all.js压缩，服务器不需要对其进行动态压缩消耗性能，直接把压缩后脚本传给客户端浏览器，由浏览器解压调用，经过测试性能确实明显提高，至此觉得这个方案比较适用。

找了一天终于在你这里发现了.我下去调试调试.谢谢了

这个类是不是和tomcat下的gzip服务一样啊？

gzip filter 性能没那么低吧？