JSF性能问题

在网上转了些时间,大家都说JSF很慢,不知道真假?

刚买了本书看,请使用过的朋友们,指点一下.

效率还是不错的,那只能看了,只能看服务器的配置了,既然买书了,自己可以好好研究下

我现在用seam集成的JSF,这是没办法,整个组都在用我也不能例外,可能是我没掌握到精髓,单页面测试还是要比struts等等慢一些。我个人非常不喜欢JSF,但是seam的其它方面还是挺好的,只要别按照示例那样做。

JSF/Struts2都是要慢的,这从其界面机制可以看出,服务器直接推出Html是最快的,比如apache,多快,不用服务器对每个Jsp文件进行过多解析,因为里面都是html语法,不用解析,是客户端浏览器解释的。

JSF/Struts2性能致命点就是掩盖了html语法,它的一个标签tag语法后面隐藏了很多html语法,那么就要耗费服务器来解析了,而且每次都不一样,缓存就帮不了忙,当然性能非常慢。

原来一直在讨论动态页面是不是比静态页面慢?Struts1.x经过这么多年证明并不算慢,因为Struts1.x基本以html为主,没有复杂的tag解析,但是JSF等就走向极端。

最后,你的系统可能输在表现层上,而不是业务层上,那是架构的失败。只能依靠CPU再上一个台阶。

其实现在业界也有另外一种解决方案,就是AJAX,Struts1.x +AJAX是性能好,又兼顾界面友好的目前最优组合设计。通过AJAX将很多复杂的界面推到客户端实现,不必由服务器解析,当然轻量了。

谢谢banq老师的指导.

不知道JSF算不算一个鸡肋啊.呵呵

JSF速度问题金蝶开源方面有篇文章专门说了这个问题。它提出这个问题主要是用一个超大的hidden保存组件树状态造成的。每次请求这个大Hidden都要在客户端和服务器之间来回传。所以造成了很大的性能损失。他们也提出了一个自己的解决方法,消灭了这个大hidden,不过这个方法要用他们的开源JSF来实现。

可以肯定的是,作为j2ee体系中的一个标准推出的jsf技术不会是个鸡肋。
jsf作为一个标准(这是它天生的优势),就会有很多团队为它写实现,写各式各样的组件库供我们选用。
你当然也可以自己写一些代码扩展一些功能,但一定要符合jsf标准的,这样你的扩展内容可以和其他的实现框架,组件库相结合。也就是要依赖于标准,去扩展实现,千万不要依赖于某个实现去扩展。
至于性能问题,我觉得要想了解它,至少要找个jsf的具体实现(例如myfaces)的源代码来研究研究,了解了解jsf那几个生命周期都在干啥,这会对你的理解有很大帮助的,不要听别人说jsf慢就认为它慢。很多情况是jsf标准定义的不错,而具体实现做得不够好。
另外,楼上说的金蝶公司的aom实现,减少了很大部分的组件状态信息,以提高性能。
具体参见 url=http://www.operamasks.org/articles/magic-8/html_single/]AOM 2.0的神奇魔力之八:消除状态--致JSF怀疑论者[/url](消除夸张了点)
[该贴被confuse于2008-10-14 15:15修改过]

以下不代表我否定JSF,首先我声明一下当前我对JSF意见:中立,JSF就象当初EJB1.X一样,立意长远,设计超前。当然,它需要Java社区象对待EJB一样,不断批判拓展,直到EJB3.x才方便自然使用。AOM是这方面探索,值得肯定。

下面谈谈反面意见:我看了一下AOM这篇文章,我想我要说的,已经有人在留言中说了:AOM还是把事情搞复杂了。

我这人喜欢巧妙简单的解决之道,排斥修修补补的解决方案,AOM这种解决方案真是需要ICP作为一个标准在下一个版本来实现,否则初学者很容易按通常JSP路线来走,你说JSP并不适合JSF,就有点那个了,我打个比喻:

从沿江高速开车进入上海收费站后,如果你不小心就无法开到市区,只能跑到青浦,为什么呢?因为进入上海市区的不是收费站以后的主大道,而是一个小的分道,要不是牌子上写市区,新手就很难知道这是通往市区,再加上这个牌子上又写“嘉定”,这又让人对这条通往市区的小道产生疑问,在高速行驶情况下,很多人就沿着当前大道开下去。这就是上海的交通设计智慧。

所以,设计是需要直觉,是感性的,说时髦话:就是以人为本。

虽然我对JSF不排斥,但是我觉得接触JSF决定JSF架构之前的人,还是先了解一下AJAX,如Prototype/JSON之类,在当前硬件条件下,让客户端做些界面的渲染是实际的,这个论坛就是采取这个架构,而且是原来Struts1.X标签上拓展的,Prototype/JSON也适合各种服务器语言平台,.NET/JRuby/PHP等,这样移植性好,这些都体现设计优雅,我反对在后台服务器嵌入AJAX,然后通过渲染,多一道弯,如果我看到别人很好的一个界面效果,就可以移植过来。

就象为什么Html/javascript成为标准,而世界上最聪明的专家制定的各种语言都没能成为互联网界面标准一样,现在这些聪明专家又想在html上再多一层复杂的封装,让我们程序员无法直接操纵html,本来直接简单的html,给这些专家搞复杂了,简单的标签库就可以了,何必要看html结果,要跑到浏览器里面看,就是到浏览器里面看源码,也不一定看得懂,这就是当前JSF最大困境,这样你就必须使用厂商的可视化开发工具,这和当初EJB1.X/2.X是一样初衷,就是搞复杂,让你手工无法方便直接做,后面还得来买我的开发工具,金蝶也是商业公司吧?

说到底,这些商业公司就是不象google那样转变软件公司盈利思路,嘴上喊SOA,实际还是靠卖软件赚钱,这种好日子不长了。

谈回来,从我个人角度出发,我认为除了界面优美方便View上需要花功夫外,MVC中,无需对Controller也就是控制层花太大力气,只要对M(Model)和V(View)花重力就可以了,至于Controller控制层用什么框架都无所谓,不就一个前后台控制嘛,要那么复杂灵活干嘛,当初只有JSP时,我们不是照样编程嘛?照样使用一个servlet来进行全局前后台控制嘛,只不过不能XML配置而已。我这是从MVC模式架构高度来谈,这是最基本的,是本质的,不要被花俏的技术细节迷失基本方向。

action层的作用感觉越来越小:
http://www.jdon.com/jivejdon/thread/33821.html

banq大哥的话还是那末的辩证呀,呵呵
我个人对jsf技术是支持的态度,主要是感觉jsf是很有可挖掘之处的,抽象点说就是很有潜力。
具体点呢,jsf技术应用到实际上是一套标准(就是一堆sun的api)+ 某个具体实现(myfaces...),合起来可以算作是个xxx框架,重点在于具体实现这部分是可以扩展的。
你可以自定义variable-resolver,el-resolver去扩展标准的EL规范,可以很aop的定义各种phase-listener,action-listener,在某种操作前后干点什莫,还可以自定义NavigationHandler去实现一些自己的导航规则(例如要跳转的url前面加个r:代表重定向,加个f:代表转发), 定义ViewHandler让你实现自己的渲染方式(前台界面也不一定是html),当然自定义的组件库更是诱人。
说了一堆的优点,感觉这可能就是banq大哥所赞同的"立意长远,设计超前"。
但是,jsf肯定也是存在问题的,一个请求要经历那末多个周期,感觉上麻烦点,应用到servlet上,返回html页面的byte数也是显得多了点。可这世上就没有不要钱的午餐,要实现某方面的好处,必然要做出另一些方面的牺牲。关键还是看这牺牲值得不,这还得具体根据自己的需要去决定了,可能有些项目更适合jsf,另一些呢,则更应该采用别的框架。