讨论Ext项目的性能优化

现在开发的项目用了Ext+Dwr，页面初始化的时间比较长（我的项目左边是树，右边使用tabPanel引入iframe），有什么优化方法呢？

 

整理各位大侠的意见如下：

方法一：

压缩传输，比如tomcat6下面启用gzip，修改server.xml的配置：
<Connector port="8081" protocol="HTTP/1.1" maxThreads="150" 
  compression="on"
  noCompressionUserAgents="gozilla, traviata" 
  compressableMimeType="text/html,text/xml,text/javascript,text/css"
  connectionTimeout="20000" redirectPort="8443" URIEncoding="GBK"/>

 

一篇介绍Gzip的文章：http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/  不错！

  

一篇介绍iframe直接使用父页面的js和css技术的文章：http://matthew.delmarters.com/weblog/injecting-javascript-and-css-into-iframes/#comment-64462 不是很明白！

 

当然还有其他的一些压缩工具：比如E3压缩。

 

方法二：

项目中Ext代码优化。

1. 不推荐使用iframe加载的方式，使用autoload。

2. 在完成了组件对象的使用以后必须回收,可以使用对应对象的destroy，beforeDestroy,removeAll等方法销毁对象以及一些孤立节点。

3. 不要把继承层次弄的太深。

。。。

评论

49 楼 icewubin 2008-11-26  

shevliu 写道

EXT在企业应用中，体积应该不成问题。
局域网传输很快，况且有缓存。

令人头疼就是加载速度
就一个普通页面：一棵树，一个20条数据的grid，再加几个form。在奔四，512内存的机器上居然需要3-5秒的加载时间，CPU占用率100%。很是郁闷

P4 频率多少？

48 楼 shevliu 2008-11-26  

EXT在企业应用中，体积应该不成问题。
局域网传输很快，况且有缓存。

令人头疼就是加载速度
就一个普通页面：一棵树，一个20条数据的grid，再加几个form。在奔四，512内存的机器上居然需要3-5秒的加载时间，CPU占用率100%。很是郁闷

47 楼 icewubin 2008-11-26  

fins 写道

我的观点:
Ext2.2 的grid , 性能提升微乎其微.
Ext所说的性能优化是纯"视觉系"的.
他只是玩了一个小花招, 延迟渲染了列表行(用了一个"伪异步"的技巧).

是不是相当于live-grid延迟渲染的效果呢？

46 楼 fins 2008-11-26  

icewubin 写道

elstage 写道

说是ext2.2优化了grid的渲染

毛估估测了下，渲染4个表格，每个数据960条，就是
ext-2.2\examples\grid\grid3.html中的本地数据源翻了5倍的结果，耗时23秒（双核迅驰1.6）。

算下来渲染一个500条数据的表格依然要花3秒，在稍微机器性能差一点的环境上，时间一定更长。

先赞一个，性能提高不少，但是依然是有限制的，也就是把原先的200条记录的上限提高到大约450条左右吧，随口估计的。

其实传统table-tr-td的表格也是有上限的，只不过上限比较高，很多人没注意而已。

我的观点:
Ext2.2 的grid , 性能提升微乎其微.
Ext所说的性能优化是纯"视觉系"的.

他只是玩了一个小花招, 延迟渲染了列表行(用了一个"伪异步"的技巧).

45 楼 icewubin 2008-11-26  

elstage 写道

说是ext2.2优化了grid的渲染

毛估估测了下，渲染4个表格，每个数据960条，就是
ext-2.2\examples\grid\grid3.html中的本地数据源翻了5倍的结果，耗时23秒（双核迅驰1.6）。

算下来渲染一个500条数据的表格依然要花3秒，在稍微机器性能差一点的环境上，时间一定更长。

先赞一个，性能提高不少，但是依然是有限制的，也就是把原先的200条记录的上限提高到大约450条左右吧，随口估计的。

其实传统table-tr-td的表格也是有上限的，只不过上限比较高，很多人没注意而已。

44 楼 elstage 2008-11-26  

icewubin 写道

nihongye 写道

icewubin 写道

nihongye 写道
1.js压缩 2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析) 3.解决内存的不释放 ext的性能问题没有多少值得讨论的。 合理利用EXT的组件进行UI设计，因为EXT的不少效果的渲染在IE下性能非常低下，比如超过100行数据的默认grid的渲染，超过200个的column布局的堆砌（这半句我自己都看不懂），动画。。。 这些情况是属于极端的... 啊，没有吧，很多初学EXT的很容易做出个100多行的grid的，用写页面方式做这种表格再正常不过了。 比如：http://fund.eastmoney.com/fund.html 然后又不清楚，这个慢到底是哪个环节造成的，开始乱猜。

说是ext2.2优化了grid的渲染

43 楼 icewubin 2008-11-26  

nihongye 写道

icewubin 写道

nihongye 写道

1.js压缩
2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析)
3.解决内存的不释放
ext的性能问题没有多少值得讨论的。

合理利用EXT的组件进行UI设计，因为EXT的不少效果的渲染在IE下性能非常低下，比如超过100行数据的默认grid的渲染，超过200个的column布局的堆砌（这半句我自己都看不懂），动画。。。

这些情况是属于极端的...

啊，没有吧，很多初学EXT的很容易做出个100多行的grid的，用写页面方式做这种表格再正常不过了。
比如：http://fund.eastmoney.com/fund.html

然后又不清楚，这个慢到底是哪个环节造成的，开始乱猜。

42 楼 nihongye 2008-11-25  

icewubin 写道

nihongye 写道

1.js压缩
2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析)
3.解决内存的不释放
ext的性能问题没有多少值得讨论的。

合理利用EXT的组件进行UI设计，因为EXT的不少效果的渲染在IE下性能非常低下，比如超过100行数据的默认grid的渲染，超过200个的column布局的堆砌（这半句我自己都看不懂），动画。。。

这些情况是属于极端的...

41 楼 icewubin 2008-11-25  

nihongye 写道

1.js压缩
2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析)
3.解决内存的不释放
ext的性能问题没有多少值得讨论的。

合理利用EXT的组件进行UI设计，因为EXT的不少效果的渲染在IE下性能非常低下，比如超过100行数据的默认grid的渲染，超过200个的column布局的堆砌（这半句我自己都看不懂），动画。。。

40 楼 nihongye 2008-11-24  

1.js压缩
2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析)
3.解决内存的不释放
ext的性能问题没有多少值得讨论的。

39 楼 kimmking 2008-11-24  

用了iframe又不autoload一定会慢很多。
解析ext-all对浏览器来说是个力气活

38 楼 icewubin 2008-11-24  

风花雪月饼 写道

126和163邮箱已经证明全AJAX应用会导致浏览器崩溃。。。

那是不是可以证明Gmail和Yahoo Mail的作者都来自火星？

37 楼 风花雪月饼 2008-11-24  

126和163邮箱已经证明全AJAX应用会导致浏览器崩溃。。。

36 楼 yourgame 2008-11-22  

zhongli 写道

生产采用的是apache的gzip压缩，好像可以达到80%，体积的问题应该很容易解决。
顺便问一下，如果不使用iframe，那是不是变成了one page application模式？这样好像不是很爽，多模块不一定都是用ext开发的

个人认为extjs这么华丽，你为什么不全部用它来开发呢？你用其他和他混用，感觉不良好

35 楼 kebo 2008-11-21  

那倒不是，主要是相互调用，通讯麻烦，parent啥的感觉依赖了页面结构。

34 楼 elstage 2008-11-21  

kebo 写道

压缩，考虑到的是网络速度的问题。如果网络不是问题，这块儿没什么用。
extjs使用的时候，就我们项目的经验。不要把继承层次弄的太深。我们项目是
坚决不用什么iframe的东西。jsvm2可以很好的做js的分割加载

用了iframe是不是一定就比不用慢呢？

33 楼 icewubin 2008-11-21  

zhongli 写道

通常一个简单的模块当作一个application.主界面调用的时候如果不用iframe那用什么调用呢？正如你说的，这个模块可能会是其他系统的，也可能会是非ext开发的

这个就复杂了，主要牵涉到两个问题。

1.页面布局，例如新浪或淘宝，不同模块这件对于用户来说没有直接的关系，也有可能是用iframe，也有可能就是各管各，完全通过页面重定向来切换模块。对于系统内部来说多半都是通过url和cookie来传递参数，比如淘宝和支付宝的页面切换时一定是带有参数的。

但是首页例外，首页往往会单独优化。

2.消息通讯，1里面提到了传递参数，通过URL跳转是最常见的一种方式，如果一定要在不同模块之间直接交互，而且有些子模块可能有些是异构的遗留系统，除了iframe我也想不出什么好办法。

32 楼 zhongli 2008-11-21  

icewubin 写道

zhongli 写道

生产采用的是apache的gzip压缩，好像可以达到80%，体积的问题应该很容易解决。
顺便问一下，如果不使用iframe，那是不是变成了one page application模式？这样好像不是很爽，多模块不一定都是用ext开发的

体积问题你说对了，也就是第一次访问需要下载112KB的ext-all.js的问题，大概相当于2-3幅大图片的大小。


一个application不等于一个网站，application的粒度需要自己把握。

多模块完全可以多page。

如果一定要多模块放在一个页面中，即使用iframe，多模块之间在客户端的通讯也是很麻烦的，建议大模块设计的时候就按照传统门户网站的策略，各自分开。比如门户的新闻页面往往基于各自的CMS系统，论坛有可能是PHP系统等等。

很荣幸又听到你的指教
通常一个简单的模块当作一个application.主界面调用的时候如果不用iframe那用什么调用呢？正如你说的，这个模块可能会是其他系统的，也可能会是非ext开发的

31 楼 elstage 2008-11-20  

客户端机器性能好一点的话还能忍受，如果客户端机器配置差那复杂页面显示就歇菜了

30 楼 jacky9692 2008-11-20  

elstage 写道

fins 写道

我觉得 不应该从js 体积上着手 那个不是最大的瓶颈 ext源码级别的优化 以及使用方式(你写的ext代码)上的优化 才是关键的 (个人观点 欢迎批驳 但我不做回应 )

你说的不错，问题是在写法优化上面有没有什么经验共享？

在完成了组件对象的使用以后必须回收,可以使用对应对象的destroy，beforeDestroy,removeAll等方法销毁对象以及一些孤立节点。
比如store使用后，可以使用它的removeAll方法销毁;form,grid等可以使用destroy销毁。。。