- 浏览: 314361 次
- 性别:
- 来自: 杭州
最新评论
-
wizard_hu:
[i]引用[img][url][flash=200,200][ ...
使用Eclipse Memory Analyzer进行内存泄漏分析三部曲 -
可爱的小狗:
学习了
HttpClient容易忽视的细节——连接关闭 -
xiajunhust:
sqtds 写道文章写的很好,浅显易懂!!! com.taob ...
使用Eclipse Memory Analyzer进行内存泄漏分析三部曲 -
zhylandroid:
使用Eclipse Memory Analyzer进行内存泄漏分析三部曲 -
dsjt:
悲剧啊,google code 被墙了
mybatis3分表插件shardbatis 2.0
最近想在一个项目中使用sitemesh作为view层的装饰器,于是今天就做了一下sitemesh的性能测试。
由于只是测试view层的性能,所以系统框架只有了spring mvc3(3.0.3)+freemarker(2.3.16)+sitemesh(2.4.2)
servlet容器:jetty-6.1.21
jdk:1.6.0_17-b04
压力测试工具:loadRunner 8.1
应用服务器配置:8cup Intel(R) Xeon(R) CPU E5410 @ 2.33GHz; 内存:4G
测试代码:
freemaker代码
sitemesh相关配置:
装饰器页面main.jsp:
30用户并发访问上面页面,jetty启动时没有使用任何jvm优化参数
不使用sitemesh时的测试结果
Visualvm的监控截图
使用sitemesh时的测试结果
Visualvm的监控截图
从上面这些测试结果来看sitemesh对页面平均响应时间的影响还是比较小的,这个影响我觉得基本可以接受。
但是从Visualvm的监控结果让我非常的惊讶,使用sitemesh以后使得jvm的内存使用剧增,是未使用之前的10倍之多,与此同时cpu的使用率也是原来的3-4倍,由于内存使用量的剧增导致jvm的GC也频繁了许多。
新做的一轮测试,供大家参考
参考 rapid-framework的继承实现方式得到的测试结果
参考老外搞的freemarker layouthttp://richardbarabe.wordpress.com/2009/03/19/freemarker-a-brief-example/ 实现方式得到的测试结果
从上面这一轮测试可以看出来这两种方案的实现效果在页面响应时间上差不多,基本没有区别。内存波动也大致相同,唯一差别较大的是,使用rapid测试的场景cpu的使用率波动较频繁,而使用宏实现的装饰器cpu波动较少,CPU使用率相对较低。
此外使用rapid的场景中线程数的波动图较其他几个场景的波动要明显,不过在测试的时候我没有注意到这个情况,所以目前还不知道线程数量增多的原因。我怀疑是在这个场景下由于请求处理的稍微慢一些,导致VVM统计的活动线程数要高于其他场景。
希望以上这些测试结果对大家有参考意义。
互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微,性能一般不会出现在这一层的,所以不用太追求这一层的绝对性能
要这么说真没啥理由不用sitemesh。这玩意太好用了
互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微,性能一般不会出现在这一层的,所以不用太追求这一层的绝对性能
这个思路的确不错,很像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
请问, 不推荐 tiles 的原因是什么?
这个思路的确不错,很像rails里面的模板系统,不过看了一下它的源码, 各个子页面渲染后也是存在request的一个attribute里面, 最后被父页面替换,这样如果一个页面很大的话应该也会跟sitemesh一样占用很多内存吧, 不过它的性能应该比sitemesh高,因为它不需要解析子页面
我也看过源码,就几十行代码就实现了整个功能. JSP的实现存在你说的问题,使用String传递override内容, 不过freemarker及velocity的实现则不是String传递,不会占用内存
其实现思路应该是比sitemesh性能高.
这个思路的确不错,很像rails里面的模板系统,不过看了一下它的源码, 各个子页面渲染后也是存在request的一个attribute里面, 最后被父页面替换,这样如果一个页面很大的话应该也会跟sitemesh一样占用很多内存吧, 不过它的性能应该比sitemesh高,因为它不需要解析子页面
由于只是测试view层的性能,所以系统框架只有了spring mvc3(3.0.3)+freemarker(2.3.16)+sitemesh(2.4.2)
servlet容器:jetty-6.1.21
jdk:1.6.0_17-b04
压力测试工具:loadRunner 8.1
应用服务器配置:8cup Intel(R) Xeon(R) CPU E5410 @ 2.33GHz; 内存:4G
测试代码:
@Controller public class TestController { @RequestMapping(value="/hello", method=RequestMethod.GET) public void sayHello(Model model){ model.addAttribute("timestamp",new Long(System.currentTimeMillis())); } }
freemaker代码
<html> <head> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> <meta http-equiv="Cache-Control" content="no-store"/> <meta http-equiv="Pragma" content="no-cache"/> <meta http-equiv="Expires" content="0"/> </head> <title>freemarker title</title> <body> <#list 1..100 as r> <#list 1..1000 as xx> <h5>${timestamp%xx}</h5> </#list> </#list> </body> </html>
sitemesh相关配置:
web.xml: <filter> <filter-name>sitemesh</filter-name> <filter-class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class> </filter> <filter-mapping> <filter-name>sitemesh</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> decorators.xml <decorators defaultdir="/decorators"> <!-- Any urls that are excluded will never be decorated by Sitemesh --> <excludes> <pattern>/exclude.jsp</pattern> <pattern>/exclude/*</pattern> </excludes> <decorator name="main" page="main.jsp"> <pattern>/*</pattern> </decorator> </decorators>
装饰器页面main.jsp:
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator" prefix="decorator" %> <%@ taglib uri="http://www.opensymphony.com/sitemesh/page" prefix="page" %> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title><decorator:title default="Mysterious page..." /></title> <decorator:head /> </head> <body> <h1>header</h1> <decorator:body /> <h1>footer</h1> </body> </html>
30用户并发访问上面页面,jetty启动时没有使用任何jvm优化参数
不使用sitemesh时的测试结果
Visualvm的监控截图
使用sitemesh时的测试结果
Visualvm的监控截图
从上面这些测试结果来看sitemesh对页面平均响应时间的影响还是比较小的,这个影响我觉得基本可以接受。
但是从Visualvm的监控结果让我非常的惊讶,使用sitemesh以后使得jvm的内存使用剧增,是未使用之前的10倍之多,与此同时cpu的使用率也是原来的3-4倍,由于内存使用量的剧增导致jvm的GC也频繁了许多。
新做的一轮测试,供大家参考
参考 rapid-framework的继承实现方式得到的测试结果
参考老外搞的freemarker layouthttp://richardbarabe.wordpress.com/2009/03/19/freemarker-a-brief-example/ 实现方式得到的测试结果
从上面这一轮测试可以看出来这两种方案的实现效果在页面响应时间上差不多,基本没有区别。内存波动也大致相同,唯一差别较大的是,使用rapid测试的场景cpu的使用率波动较频繁,而使用宏实现的装饰器cpu波动较少,CPU使用率相对较低。
此外使用rapid的场景中线程数的波动图较其他几个场景的波动要明显,不过在测试的时候我没有注意到这个情况,所以目前还不知道线程数量增多的原因。我怀疑是在这个场景下由于请求处理的稍微慢一些,导致VVM统计的活动线程数要高于其他场景。
希望以上这些测试结果对大家有参考意义。
评论
19 楼
pond918
2011-03-30
sitemesh3说是性能优化蛮多,3倍吞吐量,1/2内存消耗。楼主方便再跑一个对比测试吗
http://www.sitemesh.org/new-in-sitemesh3.html
http://www.sitemesh.org/new-in-sitemesh3.html
18 楼
skzr.org
2011-02-16
<p>
</p>
<p>曾经在项目中测试过请求登录页面</p>
<p>通过ab -k -t 200 -c (50sitemesh和100无sitemesh时) -n 1000 http://192.168.13.125:8120/xxx/login.do</p>
<p> </p>
<p>测试结果</p>
<p>使用sitemesh和去掉sitemesh之间的性能差异</p>
<p>Document Length<span style="white-space: pre;"> </span> 9251 bytes<span style="white-space: pre;"> </span> 5046 bytes</p>
<p>Concurrency Level<span style="white-space: pre;"> </span> <span style="color: #ff0000;">50</span><span style="white-space: pre;"> </span> <span style="color: #ff0000;">100</span></p>
<p>Requests per second<span style="white-space: pre;"> </span> <span style="color: #ff0000;">373.36</span> [#/sec] (mean)<span style="white-space: pre;"> </span> <span style="color: #ff0000;">715.36</span> [#/sec] (mean)</p>
<p>Transfer rate<span style="white-space: pre;"> </span> 3460.29 [Kbytes/sec] received<span style="white-space: pre;"> </span> 3735.68 [Kbytes/sec] received<span style="white-space: pre;"> </span></p>
<p> </p>
<p>1. 选择登录页面因为简单,无业务处理,尽量保持测试简单性</p>
<p>2. sitemesh在Requests per second中表现真的大吃一惊,两种可能(当时未注意网络IO吞吐瓶颈)</p>
<p> a) 服务器台式机ubuntu 9 64bit,tomcat6, jdk 1.6 64bit的,客户机:ubuntu 9 64bit, ab工具;它们连接在同一路由器上,网卡速度都是100M的</p>
<p> 我想这个网络速度应该不是瓶颈,毕竟最大才3735.68 [Kbytes/sec] ,才100M的30%</p>
<p> </p>
<p>没有象楼主一样同时关注jvm的运行情况是一大遗憾阿,以后有机会再测试下。</p>
<p> </p>
<p>在项目实际中,因为做的是业务内网上运行的管理系统,感觉sitemesh的不足:</p>
<p>1. 没事扯蛋,遇记N(>5)年不需要调整布局</p>
<p>2. 装饰时页面混乱,不通业务页面需求不一样(做管理的,页面布局千奇百怪)-->因为布局出问题时调试管理困难,牵连太多,每个都要测试</p>
<p>3. 每次传输时页面相比以前基于iframe或frameset做的框架总要多出至少1倍左右的document length</p>
<p>(最有感触的某现场相距服务器50km,还光纤专网,从windows系统copy 27M共享文件也需要几分钟的网速下,打开页面不可忍受,只能解释,看27M文件复制都要2分钟的网络,等一等没事)</p>
<p> </p>
<p>4. 性能上确实感觉慢了</p>
<p> </p>
<p>感觉rapid的include实践太好了,sitemesh还是权衡来使用吧!</p>
</p>
<p>曾经在项目中测试过请求登录页面</p>
<p>通过ab -k -t 200 -c (50sitemesh和100无sitemesh时) -n 1000 http://192.168.13.125:8120/xxx/login.do</p>
<p> </p>
<p>测试结果</p>
<p>使用sitemesh和去掉sitemesh之间的性能差异</p>
<p>Document Length<span style="white-space: pre;"> </span> 9251 bytes<span style="white-space: pre;"> </span> 5046 bytes</p>
<p>Concurrency Level<span style="white-space: pre;"> </span> <span style="color: #ff0000;">50</span><span style="white-space: pre;"> </span> <span style="color: #ff0000;">100</span></p>
<p>Requests per second<span style="white-space: pre;"> </span> <span style="color: #ff0000;">373.36</span> [#/sec] (mean)<span style="white-space: pre;"> </span> <span style="color: #ff0000;">715.36</span> [#/sec] (mean)</p>
<p>Transfer rate<span style="white-space: pre;"> </span> 3460.29 [Kbytes/sec] received<span style="white-space: pre;"> </span> 3735.68 [Kbytes/sec] received<span style="white-space: pre;"> </span></p>
<p> </p>
<p>1. 选择登录页面因为简单,无业务处理,尽量保持测试简单性</p>
<p>2. sitemesh在Requests per second中表现真的大吃一惊,两种可能(当时未注意网络IO吞吐瓶颈)</p>
<p> a) 服务器台式机ubuntu 9 64bit,tomcat6, jdk 1.6 64bit的,客户机:ubuntu 9 64bit, ab工具;它们连接在同一路由器上,网卡速度都是100M的</p>
<p> 我想这个网络速度应该不是瓶颈,毕竟最大才3735.68 [Kbytes/sec] ,才100M的30%</p>
<p> </p>
<p>没有象楼主一样同时关注jvm的运行情况是一大遗憾阿,以后有机会再测试下。</p>
<p> </p>
<p>在项目实际中,因为做的是业务内网上运行的管理系统,感觉sitemesh的不足:</p>
<p>1. 没事扯蛋,遇记N(>5)年不需要调整布局</p>
<p>2. 装饰时页面混乱,不通业务页面需求不一样(做管理的,页面布局千奇百怪)-->因为布局出问题时调试管理困难,牵连太多,每个都要测试</p>
<p>3. 每次传输时页面相比以前基于iframe或frameset做的框架总要多出至少1倍左右的document length</p>
<p>(最有感触的某现场相距服务器50km,还光纤专网,从windows系统copy 27M共享文件也需要几分钟的网速下,打开页面不可忍受,只能解释,看27M文件复制都要2分钟的网络,等一等没事)</p>
<p> </p>
<p>4. 性能上确实感觉慢了</p>
<p> </p>
<p>感觉rapid的include实践太好了,sitemesh还是权衡来使用吧!</p>
17 楼
flashing
2010-07-22
zelsa 写道
flashing 写道
这是架构师需要权衡的部分了。
如果你做一个企业应用,页面并发不大,业务要求高的,sitemesh可以为你解决很多麻烦;但是你做互联网应用,页面并发大的,sitemesh可能性能就不够极致了。
得权衡的。
如果你做一个企业应用,页面并发不大,业务要求高的,sitemesh可以为你解决很多麻烦;但是你做互联网应用,页面并发大的,sitemesh可能性能就不够极致了。
得权衡的。
互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微,性能一般不会出现在这一层的,所以不用太追求这一层的绝对性能
要这么说真没啥理由不用sitemesh。这玩意太好用了
16 楼
zelsa
2010-07-22
flashing 写道
这是架构师需要权衡的部分了。
如果你做一个企业应用,页面并发不大,业务要求高的,sitemesh可以为你解决很多麻烦;但是你做互联网应用,页面并发大的,sitemesh可能性能就不够极致了。
得权衡的。
如果你做一个企业应用,页面并发不大,业务要求高的,sitemesh可以为你解决很多麻烦;但是你做互联网应用,页面并发大的,sitemesh可能性能就不够极致了。
得权衡的。
互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微,性能一般不会出现在这一层的,所以不用太追求这一层的绝对性能
15 楼
flashing
2010-07-22
这是架构师需要权衡的部分了。
如果你做一个企业应用,页面并发不大,业务要求高的,sitemesh可以为你解决很多麻烦;但是你做互联网应用,页面并发大的,sitemesh可能性能就不够极致了。
得权衡的。
如果你做一个企业应用,页面并发不大,业务要求高的,sitemesh可以为你解决很多麻烦;但是你做互联网应用,页面并发大的,sitemesh可能性能就不够极致了。
得权衡的。
14 楼
badqiu
2010-07-21
很好,以后rapid的布局可以有性能测试数据可查
13 楼
超级潜水员
2010-07-21
照结果来看,freemarker-a-brief-example及rapid-framework在CPU消耗及内存消耗都比sitemesh低。
十分好的测试比较。
十分好的测试比较。
12 楼
SeanHe
2010-07-20
已经补上新的对比测试结果
推荐大家再看一下
推荐大家再看一下
11 楼
超级潜水员
2010-07-19
十分期待LZ对这几种布局的性能测试比较.
10 楼
SeanHe
2010-07-19
超级潜水员 写道
climber2002 写道
超级潜水员 写道
不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.
其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends
性能也比sitemesh好很多.
可以考虑使用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
9 楼
zelsa
2010-07-19
用sitemesh就是用空间换时间,也就是用大内存去换取性能,不过现在内存便宜,考虑到sitemesh对开发带来的便利性,还是非常值得的
8 楼
tapestry1122
2010-07-19
sitemesh解析html性能应该是没问题的
他们为了提供解析性能是手写的一个html parser
playframework到是用的继承思路,不过由于是groovy的,性能没有rapid的好
不过有人另外实现了一个japid
他们为了提供解析性能是手写的一个html parser
playframework到是用的继承思路,不过由于是groovy的,性能没有rapid的好
不过有人另外实现了一个japid
7 楼
iamjxc
2010-07-19
超级潜水员 写道
不推荐使用tiles.
请问, 不推荐 tiles 的原因是什么?
6 楼
超级潜水员
2010-07-19
climber2002 写道
超级潜水员 写道
不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.
其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends
性能也比sitemesh好很多.
可以考虑使用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性能高.
5 楼
climber2002
2010-07-19
超级潜水员 写道
不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.
其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends
性能也比sitemesh好很多.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.
其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends
性能也比sitemesh好很多.
这个思路的确不错,很像rails里面的模板系统,不过看了一下它的源码, 各个子页面渲染后也是存在request的一个attribute里面, 最后被父页面替换,这样如果一个页面很大的话应该也会跟sitemesh一样占用很多内存吧, 不过它的性能应该比sitemesh高,因为它不需要解析子页面
4 楼
超级潜水员
2010-07-18
不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.
其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends
性能也比sitemesh好很多.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.
其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends
性能也比sitemesh好很多.
3 楼
srdrm
2010-07-18
这个测试很有意义
sitemesh 一般用于遗留系统改造,页面太多,原来也没有结构化设计,实现的情况下,sitemesh 或许是条路。
新的系统不应该用sitemesh, 考虑 tiles 等。
sitemesh 一般用于遗留系统改造,页面太多,原来也没有结构化设计,实现的情况下,sitemesh 或许是条路。
新的系统不应该用sitemesh, 考虑 tiles 等。
2 楼
SeanHe
2010-07-17
TPS应该和我故意在Freemarker里用了个双重循环的缘故,这么写我也是为了测试一下freemarker的性能
1 楼
kimmking
2010-07-17
hits少15%。
cpu是2-3倍。
内存大10几倍。
-----------
这个测试的tps小成这样,有实际意义吗?
另外建议监控用LoadRunner+istatd,别用vvm
cpu是2-3倍。
内存大10几倍。
-----------
这个测试的tps小成这样,有实际意义吗?
另外建议监控用LoadRunner+istatd,别用vvm
发表评论
-
mybatis3分表插件shardbatis 2.0
2011-07-23 14:08 22176shardbait2.0实现分表的功能可以用一句话描述:使用m ... -
运行Apache Mahout的Taste Webapp例子
2011-07-14 20:00 10394Apache Mahout 是 Apache Soft ... -
编程式配置Spring bean
2011-02-15 23:29 2582今晚翻看了以前写的RPC框架。发现这个框架中编程式配置Spri ... -
JVM Crash原因分析及相关资料
2011-02-14 15:53 14989去年生产环境突然有一天连续发生几台服务器JVM Crash的情 ... -
一次jboss中部署应用时类版本冲突问题分析、解决过程
2011-02-10 10:11 9983去年同事的一个项目在JBOSS中部署时遇到类版本冲突问题,当时 ... -
java nio学习笔记
2011-01-30 00:37 0通道 和 缓冲区 是 NIO 中的核心对象,几乎在每一个 I/ ... -
使用Eclipse Memory Analyzer进行内存泄漏分析三部曲
2011-01-27 14:40 36672一、准备工作 分析较大的dump文件(根据我自己的经验2G以上 ... -
JBoss、Tomcat Classloader不完全分析
2010-12-14 13:25 3824由于平时项目中用到的还是JBoss 4.2.x所以我这里的分析 ... -
通过ibatis实现轻量级的水平切分(已更新,ibatis原生api也可以实现sharding)
2010-08-31 23:07 11798最近想在自己的项目里 ... -
Spring对Quartz的封装实现简单分析及使用注意事项
2010-06-14 14:08 9930前段时间在项目中一直使用正常的Quartz突然出现了任务漏跑的 ... -
Google App Engine for Java 开发笔记
2009-07-25 23:01 1845最近使用GAE开发一个小应用,开发过程中发现几个问题在这里做下 ... -
HttpClient容易忽视的细节——连接关闭
2008-08-30 12:22 130881HttpClient client = new HttpC ... -
为Hessian加入加密签名的安全机制
2008-03-09 10:01 6010Hessian是轻量级的RMI实现使用起来非常的方便,同时与S ... -
java DSA签名实现
2008-03-08 21:50 7224通过以下工具类可以生成DSA公钥和私钥文件 /** * ...
相关推荐
2. **使用SiteMesh**:集成SiteMesh后,再次进行性能测试。 3. **负载测试**:模拟不同并发用户数量,观察系统的响应时间。 **实验结果** - 在低并发情况下,使用SiteMesh对性能影响不大。 - 随着并发用户数的增加...
**Sitemesh** 是一个广泛使用的开源Web应用框架,它主要功能是提供页面布局和装饰功能,用于统一网站的外观和感觉。Sitemesh通过在Web应用中引入“母版”(Master Page)的概念,使得开发者可以轻松地创建一致性的...
7. **调试和测试**:文档中还会介绍如何查看 SiteMesh 的日志输出,以及如何在开发阶段快速检查装饰效果。 通过研究这个"siteMesh demo+文档",开发者可以快速掌握SiteMesh的基本使用,同时也能了解其在实际项目中...
1. **版本兼容性**:较新的Web技术和前端框架可能与Sitemesh存在兼容问题。 2. **复杂性**:对于简单的页面布局,使用Sitemesh可能显得过度工程化。 在提供的压缩包中,"SiteMesh"可能包含了Sitemesh的源码、文档、...
当你访问一个页面时,Sitemesh会捕获响应,应用装饰器模板,并将结果返回给浏览器。这样,即使你的每个页面代码独立编写,也可以实现全局一致的布局。 为了进一步控制装饰过程,Sitemesh提供了多种特性。例如,你...
5. **运行与测试**:在MyEclipse中部署Openfire项目,启动服务器后,访问任意页面,如果页面被正确装饰,说明Sitemesh已经成功集成。 在提供的`demo`文件中,可能包含了具体的装饰模板、Openfire的配置示例以及部署...
Spring MVC 是一个强大的Java Web开发框架,用于构建可维护、高性能和灵活的Web应用程序。它提供了模型-视图-控制器(MVC)架构,使得开发者可以将业务逻辑、数据处理和用户界面清晰地分离,提高了代码的可测试性...
SiteMesh 是一个开源的Web应用程序框架,主要用于帮助开发者实现页面布局和装饰功能。它通过拦截HTTP请求,将页面内容与布局模板相结合,从而提供了一种简单有效的方式来管理和控制Web应用的外观和感觉。在Web开发中...
**Sitemesh简介** Sitemesh 是一个开源的 Web 应用程序装饰框架,主要用于解决网页布局和页面统一风格的问题。它通过拦截 HTTP 请求,将请求的页面内容与预先定义好的模板结合,使得开发者可以轻松地创建出统一的...
此外,提供的"简单文档说明"可能详细介绍了如何设置和运行这个例子,包括安装Sitemesh库、配置Web应用、创建装饰器和测试页面等步骤。阅读这份文档可以帮助初学者快速上手。 总的来说,Sitemesh是一个强大的工具,...
- **性能考虑**:虽然Sitemesh简化了页面布局的处理,但在大型项目中仍需关注性能问题,特别是在部署到生产环境时,需确保资源的高效加载和缓存策略的有效实施。 通过上述步骤,可以有效地将Freemarker和Sitemesh...
sitemesh.jar包 sitemesh.jar 包sitemesh.jar 包sitemesh.jar包
Sitemesh3是Sitemesh项目的第三个主要版本,提供了更现代的API和性能改进。 在Sitemesh3的官方下载包中,通常会包含以下几个关键部分: 1. **lib** 目录:这个目录包含了Sitemesh3运行所需的库文件。这些jar文件...
Sitemesh3是Sitemesh的第三个主要版本,相比之前的版本,它提供了更好的性能和更现代的API。在配置和使用Sitemesh3时,开发者需要了解以下几个核心概念: 1. **装饰器(Decorator)**: 装饰器是Sitemesh的核心,它...
SiteMesh是一个网页布局和装饰框架以及Web应用程序集成框架,可帮助创建由页面组成的网站,这些页面需要一致的外观,导航和布局方案。 SiteMesh会拦截对通过Web服务器请求的任何静态或动态生成的HTML页面的请求,...
- **javacpp-1.3.2.jar**:这可能是JavaCPP库的一个版本,它提供了一个接口,可以直接在Java中调用C++代码,可能会用于Sitemesh的一些底层性能优化或者特定功能实现。 **应用实例**: Sitemesh常被用于大型企业级...
### Sitemesh 3 的使用及配置 #### 一、Sitemesh 3 简介 Sitemesh 是一个非常实用的Web页面布局与修饰框架,它通过Servlet中的Filter来实现网页的装饰功能,类似于ASP.NET中的“母版页”技术。这种技术允许开发者...
而Sitemesh则是一个页面布局和装饰框架,主要用于处理Web应用中的页面布局问题,比如统一头部、底部和侧边栏,提升用户体验并简化开发。 将Spring MVC与Sitemesh结合使用,可以实现更高效的Web应用开发。以下是对这...
#### 二、Sitemesh与Struts Tiles的比较 尽管Struts Tiles在一定程度上实现了页面布局的功能,但与Sitemesh相比仍存在明显差异: - **装饰模式的应用**:Sitemesh采用了GOF的装饰者模式,并将其应用于过滤器中,这...