|
精华帖 (0) :: 良好帖 (11) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-07-19
超级潜水员 写道 climber2002 写道 超级潜水员 写道 不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局. 其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends 性能也比sitemesh好很多. 这个思路的确不错,很像rails里面的模板系统,不过看了一下它的源码, 各个子页面渲染后也是存在request的一个attribute里面, 最后被父页面替换,这样如果一个页面很大的话应该也会跟sitemesh一样占用很多内存吧, 不过它的性能应该比sitemesh高,因为它不需要解析子页面 我也看过源码,就几十行代码就实现了整个功能. JSP的实现存在你说的问题,使用String传递override内容, 不过freemarker及velocity的实现则不是String传递,不会占用内存 其实现思路应该是比sitemesh性能高. 看了一下rapid-framework框架的继承方式，在开发时感觉和这个老外搞的freemarker layouthttp://richardbarabe.wordpress.com/2009/03/19/freemarker-a-brief-example/功能有点类似，不同的是哪个老外用宏的方式实现的，具体两者之间的性能我后续也会测试一样，如果感兴趣的朋友可以关注一下。 另外我看到badqiu rapid-framework框架的作者，有一种更加优雅的实现方式《扩展freemarker,velocity,实现模板的管道操作》http://badqiu.iteye.com/blog/568709使用这种方式的话开发的时候可以不需要再子页面里写哪些额外的include的标签，开发人员只需要关注本页面的内容就好了。 其实这个和一个apache比较老的框架turbine的view的思想有点相似，turbine将页面分成layout,navigation,screen，control等，一般开发时只需要完成screen即可，外围的页面框架之类的turbine会按照默认规则去渲染好以后最后返回给客户端一个完整的html |
| 返回顶楼 | |
|
发表时间：2010-07-19
最后修改：2010-07-19
十分期待LZ对这几种布局的性能测试比较.
|
| 返回顶楼 | |
|
发表时间：2010-07-20
已经补上新的对比测试结果
推荐大家再看一下 |
| 返回顶楼 | |
|
发表时间：2010-07-21
照结果来看，freemarker-a-brief-example及rapid-framework在CPU消耗及内存消耗都比sitemesh低。
十分好的测试比较。 |
| 返回顶楼 | |
|
发表时间：2010-07-21
很好，以后rapid的布局可以有性能测试数据可查
|
| 返回顶楼 | |
|
发表时间：2010-07-22
这是架构师需要权衡的部分了。
如果你做一个企业应用，页面并发不大，业务要求高的，sitemesh可以为你解决很多麻烦；但是你做互联网应用，页面并发大的，sitemesh可能性能就不够极致了。 得权衡的。 |
| 返回顶楼 | |
|
发表时间：2010-07-22
flashing 写道 这是架构师需要权衡的部分了。
如果你做一个企业应用，页面并发不大，业务要求高的，sitemesh可以为你解决很多麻烦；但是你做互联网应用，页面并发大的，sitemesh可能性能就不够极致了。 得权衡的。 互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微，性能一般不会出现在这一层的，所以不用太追求这一层的绝对性能 |
| 返回顶楼 | |
|
发表时间：2010-07-22
zelsa 写道 flashing 写道 这是架构师需要权衡的部分了。
如果你做一个企业应用，页面并发不大，业务要求高的，sitemesh可以为你解决很多麻烦；但是你做互联网应用，页面并发大的，sitemesh可能性能就不够极致了。 得权衡的。 互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微，性能一般不会出现在这一层的，所以不用太追求这一层的绝对性能 要这么说真没啥理由不用sitemesh。这玩意太好用了 |
| 返回顶楼 | |
|
发表时间：2011-02-16
曾经在项目中测试过请求登录页面 通过ab -k -t 200 -c (50sitemesh和100无sitemesh时) -n 1000 http://192.168.13.125:8120/xxx/login.do
测试结果 使用sitemesh和去掉sitemesh之间的性能差异 Document Length 9251 bytes 5046 bytes Concurrency Level 50 100 Requests per second 373.36 [#/sec] (mean) 715.36 [#/sec] (mean) Transfer rate 3460.29 [Kbytes/sec] received 3735.68 [Kbytes/sec] received
1. 选择登录页面因为简单，无业务处理，尽量保持测试简单性 2. sitemesh在Requests per second中表现真的大吃一惊，两种可能（当时未注意网络IO吞吐瓶颈） a) 服务器台式机ubuntu 9 64bit，tomcat6, jdk 1.6 64bit的，客户机：ubuntu 9 64bit， ab工具;它们连接在同一路由器上，网卡速度都是100M的 我想这个网络速度应该不是瓶颈，毕竟最大才3735.68 [Kbytes/sec] ，才100M的30%
没有象楼主一样同时关注jvm的运行情况是一大遗憾阿，以后有机会再测试下。
在项目实际中，因为做的是业务内网上运行的管理系统，感觉sitemesh的不足： 1. 没事扯蛋，遇记N（>5）年不需要调整布局 2. 装饰时页面混乱，不通业务页面需求不一样（做管理的，页面布局千奇百怪）-->因为布局出问题时调试管理困难，牵连太多，每个都要测试 3. 每次传输时页面相比以前基于iframe或frameset做的框架总要多出至少1倍左右的document length （最有感触的某现场相距服务器50km，还光纤专网，从windows系统copy 27M共享文件也需要几分钟的网速下，打开页面不可忍受，只能解释，看27M文件复制都要2分钟的网络，等一等没事）
4. 性能上确实感觉慢了
感觉rapid的include实践太好了，sitemesh还是权衡来使用吧！ |
| 返回顶楼 | |
|
发表时间：2011-03-30
sitemesh3说是性能优化蛮多，3倍吞吐量，1/2内存消耗。楼主方便再跑一个对比测试吗
http://www.sitemesh.org/new-in-sitemesh3.html  
|
| 返回顶楼 | |
