久别大家一年了,其实这一年我从简单实现了一个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加入:
Java代码
<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>
<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,流量随着文件的压缩而减少,效果也很明显,查其原因,应该是因为压缩和解压对服务器和浏览器的资源消耗,而且是在本机测试,本机排除了带宽的影响,所以压缩前性能反而高了。
由于我研究的时间不长,在压力测试方面还没在实际项目中测试,不能一概而论,初步分析,如果是局域网项目,带宽不受限制,不使用压缩性能会好点,而对于互联网环境则要考虑压缩方案,也希望有兴趣的开发者共同研究一下这个解决方案在实际项目中的可行性,希望大家讨论。
由于现在项目越来越大,而且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加入:
Java代码
<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>
<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,流量随着文件的压缩而减少,效果也很明显,查其原因,应该是因为压缩和解压对服务器和浏览器的资源消耗,而且是在本机测试,本机排除了带宽的影响,所以压缩前性能反而高了。
由于我研究的时间不长,在压力测试方面还没在实际项目中测试,不能一概而论,初步分析,如果是局域网项目,带宽不受限制,不使用压缩性能会好点,而对于互联网环境则要考虑压缩方案,也希望有兴趣的开发者共同研究一下这个解决方案在实际项目中的可行性,希望大家讨论。