在tapestry与jsf的对比中,貌似jsf相对要快一些。
从实现原理及生命周期上看,JSF应该要比struts2要慢一些。

解决方案 »

  1.   

    struts2.x/webwork之所以比struts1.x慢可能是对每个访问新建一个Action实例有关,这样在简单应用中由于struts1.x采用单例不需要频繁创建销毁速度要快一些;但在Action处理周期比较长的情况下,struts1.x的单例就会造成等待,此时前者平均响应会更快。(这种情况spring也存在,当然spring可以根据情况设成单例还是多例)
      

  2.   

    性能瓶颈从来都不在mvc框架上。
      

  3.   

    性能瓶井确实一般出现在类似数据库这些地方。
    但某些网站业务要求很高的页面响应速度(不是AJAX交互),而后台数据都已经缓存到了系统中,单独测试时发现瓶井确实是在展现层上。
    我们现在希望就是改善展现层的性能。
      

  4.   

    目前只用到Tapestry和Struts ,性能方面没有明显差别
    我认为MVC框架本身不是影响大量并发访问网站性能的瓶颈。
    对于并发量高的网站性能优化的建议:
    1。使用健壮高效的数据库连接池技术
    2。优化数据访问层的代码,以减少访问数据时的资源消耗
    3。对可能存在大量数据的页面实施分页
    4。简洁的网页界面设计
    5。除需频繁访问数据库的动态页面用常规MVC框架,其它以静态内容为主的页面可以采用XML/XSL技术来提高整体性能
      

  5.   

    性能瓶井确实一般出现在类似数据库这些地方。
    但某些网站业务要求很高的页面响应速度(不是AJAX交互),而后台数据都已经缓存到了系统中,单独测试时发现瓶井确实是在展现层上。
    我们现在希望就是改善展现层的性能。----------------------------展现层可以考虑结合一些模板来显示,比如freeer等,接近静态页面的速度。
      

  6.   

    有自己行业的框架最好不过了,最好不要用struts+hibernate+spring
    太不稳定了,如果第一期项目用的是hibernate2.0第二期又要用hibernate3.0,最后放到一起,你就会知道有很大问题.
      

  7.   

    一般小应用不要用spring,hibernate,struts框架,不好控制。
    struts的加载struts-config-XX.xml的时候很耗资源的。
    spring加载bean时也很耗资源。
    我深受其害。
    总之,对框架不熟悉的话建议不要使用。会死人的。!^-^
      

  8.   

    我觉得Struts2比1慢,一方面有上面说的每次创建新的实例有关,但是在使用Spring管理Action的情况下,我觉得Struts2也比1要慢,我觉得它的标记库有些原因。
      

  9.   

    有人做过实验循环测试
    jsp只用了4秒就结束了20000*20000的循环
    而asp php 却分别用了63秒和84秒
    根本不是一个数量级
      

  10.   

    性能瓶颈从来都不在mvc框架上——这个比较正确
    什么ajax数据库之类的可以有所优化但不是根本、硬件和缓存才有效。
      

  11.   

    jsp原始最快,谈到框架带来了方便、宜维护等好处时,势必回有这样那样的消耗,看实际需要了。
      

  12.   

       看性能的高低应该看经过几道封装,以及如何封装.一般来说,封装的越多,越复杂,性能就越低.Struts+Hibernate+Spring框架性能确实很低,而且对于开发人员来讲也不是那么“理想”,比如在灵活性,简便性等方面,这也正是ibatis,struts2等被越来越多地采用的原因吧!纯属个人见解,请高手多指教,先谢了。