久別大家一年了，其實(shí)這一年我從簡(jiǎn)單實(shí)現(xiàn)了一個(gè)Yui-Ext0.33項(xiàng)目后，基本沒有在Ajax表現(xiàn)層花太多的時(shí)間，而是轉(zhuǎn)向研究Jbpm和WebService在項(xiàng)目中的應(yīng)用，而且大半年前Ext推出1.0版本，感覺在項(xiàng)目中升級(jí)使用還不夠成熟，所以在項(xiàng)目中繼續(xù)應(yīng)用小巧的0.33版，基本滿足需要。

由于現(xiàn)在項(xiàng)目越來越大，而且Ext2已經(jīng)推出，界面實(shí)在充滿誘惑，相信商業(yè)化的Ext2將更適合項(xiàng)目開發(fā)，所以現(xiàn)在對(duì)Ext2一些關(guān)鍵問題進(jìn)行研究，首當(dāng)其沖要解決的就是ext-all.js(512K)太大的問題。

針對(duì)js包太大的問題，有兩個(gè)現(xiàn)在比較流行的解決方案：
1. 使用jsbuild等工具把需要調(diào)用的js重新包裝，此方法的缺點(diǎn)是Ext用的最多的是form和grid等控件，刪減后包容量減少不明顯，而且我是打包了幾次失敗，就沒耐心了，當(dāng)然，要做到最好調(diào)優(yōu)，這個(gè)方案是要考慮的，基本方法就是頁面調(diào)用核心的ext-core.js，然后再把頁面要用的包自己包裝。

2. 使用gzip在服務(wù)器端犧牲一點(diǎn)cpu資源進(jìn)行壓縮，有效減低傳輸流量，由瀏覽器解壓處理后執(zhí)行。這個(gè)解決方案另我眼前一亮，其實(shí)也不是什么新東西，2005年的老東西了，只是當(dāng)時(shí)沒有想到j(luò)s會(huì)如此龐大，但現(xiàn)在老技術(shù)還是很實(shí)用的。下面將重點(diǎn)研究這個(gè)解決方案。

第一步，在web.xml增加一個(gè)gzipfilter，不用自己寫，有現(xiàn)成的，到地址：http://sourceforge.net/projects/filterlib下載，新建一個(gè)測(cè)試項(xiàng)目，最簡(jiǎn)單就在index.jsp直接調(diào)用ext-all.js，把tk-filters.jar拷貝到項(xiàng)目的lib目錄，然后在web.xml加入：

	<filter>
<filter-name>CompressingFilter</filter-name>
<filter-class>
com.tacitknowledge.filters.gzipfilter.GZIPFilter
</filter-class>
</filter>
<!-- 這里按自己許多針對(duì)不同文件進(jìn)行filter-mapping配置，比如*.css -->
<filter-mapping>
<filter-name>CompressingFilter</filter-name>
<url-pattern>*.js</url-pattern>
</filter-mapping>

第二步，調(diào)試，調(diào)試js現(xiàn)在發(fā)現(xiàn)最好的工具應(yīng)該是FireFox+firebug(插件),FireFox我用1.5版本，調(diào)試足夠了，我使用Weblogic作調(diào)試服務(wù)器，tomcat也可以，但我的tomcat在server.xml直接配置gzip壓縮功能，所以用weblogic免得測(cè)試不出來。啟動(dòng)項(xiàng)目后，用Firefox打開index.jsp頁面，頁面調(diào)出后可能會(huì)有腳本錯(cuò)誤，但可以不管，關(guān)鍵看文件的大小，打開工具->firebug->open firebug,尋找net項(xiàng)，即可看到調(diào)用的ext-all.js的壓縮效果，如附圖的比較，效果不錯(cuò)吧，512K => 137K，如果發(fā)現(xiàn)js壓縮沒效果，注意打開工具->清除私隱數(shù)據(jù)，清掉可能存在的cache，再刷新頁面重試。

第三步，壓力測(cè)試，我使用loadrunner7.8測(cè)試，簡(jiǎn)單實(shí)用，沒有8.0以上版本的華麗和慢。使用1000個(gè)進(jìn)程測(cè)試，發(fā)現(xiàn)了意外的結(jié)果(見附圖)，在本機(jī)測(cè)試，不用gzip壓縮只用了36秒，而使用gzip壓縮后則是1分49秒，流量在壓縮后從1,315,914,600降到313，125，680，流量隨著文件的壓縮而減少，效果也很明顯，查其原因，應(yīng)該是因?yàn)閴嚎s和解壓對(duì)服務(wù)器和瀏覽器的資源消耗，而且是在本機(jī)測(cè)試，本機(jī)排除了帶寬的影響，所以壓縮前性能反而高了。

由于我研究的時(shí)間不長(zhǎng)，在壓力測(cè)試方面還沒在實(shí)際項(xiàng)目中測(cè)試，不能一概而論，初步分析，如果是局域網(wǎng)項(xiàng)目，帶寬不受限制，不使用壓縮性能會(huì)好點(diǎn)，而對(duì)于互聯(lián)網(wǎng)環(huán)境則要考慮壓縮方案，也希望有興趣的開發(fā)者共同研究一下這個(gè)解決方案在實(shí)際項(xiàng)目中的可行性，希望大家討論。