2008-04-09

EXT的性能讨论

关键字: ext

      我在刚开始做友财网的时候，就一直在犹豫是否使用EXT2.0，因为大家都知道ext-all.js这个文件就是压缩过后都是496K,这对于网站来说，光下载这个js就要花费大概4S的时间，如果网络不好可能更长。但是EXT的效果让我着迷，感觉比一般客户端的软件效果都好，最好我还是打算用EXT2.0做网站。

       通过好多朋友在全国各地测试网站的速度，发现第一次打开网页的时间大概是6秒左右，关了浏览器，第二次打开<1s。说明浏览器会自动缓存这个让人头痛的js，这一点让我很高兴！

       其次好多人说EXT的Grid性能有问题，我不同意这个说法，我觉得ext2.0的Grid性能很好，并且我在多台配置比较差的机器上都试过，没有网上那么多人所说的那么差。但是有一点一定要注意，一定要在后台采用分页的形式来反应数据，如果一次显示1000条数据，差一点配置的机器，可能浏览器会死掉！

       现在网站已经放到了外网上了，你们可以看一看速度，没有见过EXT的看一看EXT的效果。友财网 http://www.ucai8.com

评论
ffychina 2008-07-28
路过,很了不起,这是我见到的第一个EXT网站.
ldjsyl 2008-04-17
引用
瓶颈主要还是在于JS是解释执行的，如果有JS虚拟机的话，渲染速度一定能大幅提升，就像Flash那样。

那么怎么有效的解决这个瓶颈呢？
j_butterfly 2008-04-15
共同进步~~：）
笨笨狗 2008-04-15
引用
非常感谢笨笨狗 的代码


这个……要是 没有后面那三个字该多好啊，哈哈哈哈。

谈不上请教，共同进步吧，我只是对前端比较感兴趣，恰巧又对Prototype这个框架比较熟悉而已（正巧这个导航条实现也能体现出Prototype的灵活强大），如果有css和这方面的问题，可以一起交流：）
j_butterfly 2008-04-15
非常感谢笨笨狗 的代码~~让我也学了不少东西~~Script高手了~以后要多多请教了：）
icewubin 2008-04-15
引用
还可以 只是访问量不是很大 不知道以后用户多的情况下会是什么情况！


访问量多了，就要看前后台数据交互设计和后台业务逻辑设计和缓存使用是否恰当。和前台用的渲染框架已经没关系了。

就我的了解来说，EXT支持多种主流的和服务端通讯的机制，没有什么限制，主要还是看交互模式设计者的功力了。
笨笨狗 2008-04-15
我已经把那个导航条发布了，大家可以到这里下载：

http://scriptfans.javaeye.com/blog/182840

欢迎大家来交流，并提意见啊：）
enjoyeveryday 2008-04-15
还可以 只是访问量不是很大 不知道以后用户多的情况下会是什么情况！
bellstar 2008-04-14
用JSI导入
j_butterfly 2008-04-14
引用
右上角那个导航俺用Prototype+script.aculo.us自己实现了一个，html代码结构更简洁，有需要的可以联系我

呵呵。。好东西就直接发上来了吧~~
fins 2008-04-14
笨笨狗 你就直接发上来吧 别让大家联系你了 哈哈
笨笨狗 2008-04-14
右上角那个导航俺用Prototype+script.aculo.us自己实现了一个，html代码结构更简洁，有需要的可以联系我
icewubin 2008-04-14
引用
我感觉EXT慢，应该主要是他自己本身的代码机制问题。
它里面的多类继承，消耗很大。挺影响速度的。


即使你说的是对的，那还是客户端运行速度（包括渲染）慢，和网络传送关系不大。
bobu 2008-04-14
我感觉EXT慢，应该主要是他自己本身的代码机制问题。
它里面的多类继承，消耗很大。挺影响速度的。
j_butterfly 2008-04-13
非常感谢icewubin的解答，让我学到了不少的东西~~~
icewubin 2008-04-13
引用
不太明白，压缩完了后，在浏览器端进行解压吗？如果这么好的东西，为什么EXT官方网上一点也没有提？你能说清楚一点吗？


这和EXT官方网站一点关系都没有，这是HTTP的传送协议的一部分，用压缩数据的方式来降低网络流量，据测整个网页可以高达66%-90%的压缩率（因为图片已经是压缩格式了，再压缩不能减少很多，而且一般服务段压缩是排除图片的，只压文本类型的），也就说能提高传送效率2.8倍以上。
icewubin 2008-04-13
引用
据我所知：
(1)EXT的交互效果似乎可以稍稍掩盖其速度慢的缺陷。没有十全十美的事。其实，我们的关注点应该重点放在EXT的完美交互上。所以，我们没有必要所有的地方都用Ext,当需要用Ext改善交互性的时候才用。
(2)另外，ext-all.js，ext-base.js这两个包，应该不是任何时候都需要引入其全部函数，大部分时候，我们只需要引用其中极少函数。我想如果我们能按需引用，每个页面只加载所需函数，或许对速度问题会有一个全新的方案。
总之，我支持Ext.


看来很多人对这个“速度慢”是理解有问题的，EXT所谓的速度慢是指客户端渲染速度慢，而不是网络传输上的，本身包的大小可以有各种方法减少网络流量，而客户端和服务端数据通讯的流量则完全取决于系统的设计，和EXT本身无关。在首次下载应用包本身来讲，绝对是比Flash插件要小很多的，要比就和flash比，不要去和其他基础框架比，ext不是基础框架。

回过头来说，即使拿EXT和同等效果的其他JS框架（其实其他框架的效果是不如EXT的），或者某些人自己写出来的效果来比，EXT应该是比较高效的。有机会你们看看EXT的源代码，会明白我的意思的。瓶颈主要还是在于JS是解释执行的，如果有JS虚拟机的话，渲染速度一定能大幅提升，就像Flash那样。
icewubin 2008-04-13
引用
这样浏览器会不会，刚下载完JS后，CPU100%几秒左右？解压的效率高吗？每次都解压还是缓存解压过的？如果每次都解压，我觉得还不如不压缩。这个说法对不？


不会，你可以拿纯html来做以排除渲染的干扰，测试结果是CPU几乎都不动的，相当于winzip去解压缩一个100KB的小文件，占用CPU能有多少？

或者说和渲染的时间比起来，解压缩的时间可以忽略不计。

在或者说，和网络等待的时间比起来，这点时间完全可以不考虑，网络传输上节省的时间也是绝对值得的。
ssprt 2008-04-12
据我所知：
(1)EXT的交互效果似乎可以稍稍掩盖其速度慢的缺陷。没有十全十美的事。其实，我们的关注点应该重点放在EXT的完美交互上。所以，我们没有必要所有的地方都用Ext,当需要用Ext改善交互性的时候才用。
(2)另外，ext-all.js，ext-base.js这两个包，应该不是任何时候都需要引入其全部函数，大部分时候，我们只需要引用其中极少函数。我想如果我们能按需引用，每个页面只加载所需函数，或许对速度问题会有一个全新的方案。
总之，我支持Ext.
tntxia 2008-04-12
我也很喜欢EXT，有时如果怕用户等太久了，我会先做一个等待页面。
发表评论

您还没有登录，请登录后发表评论

j_butterfly
  • 浏览: 9287 次
  • 性别: Icon_minigender_1
  • 来自: 乌鲁木齐
  • 详细资料
搜索本博客
博客分类
最近加入圈子
存档
最新评论