|
精华帖 (0) :: 良好帖 (11) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-07-17
最后修改：2010-07-20
最近想在一个项目中使用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 测试代码：
@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统计的活动线程数要高于其他场景。 希望以上这些测试结果对大家有参考意义。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-07-17
hits少15%。
cpu是2-3倍。 内存大10几倍。 ----------- 这个测试的tps小成这样，有实际意义吗？ 另外建议监控用LoadRunner+istatd，别用vvm |
| 返回顶楼 | |
|
发表时间：2010-07-17
TPS应该和我故意在Freemarker里用了个双重循环的缘故，这么写我也是为了测试一下freemarker的性能
|
| 返回顶楼 | |
|
发表时间：2010-07-18
这个测试很有意义
sitemesh 一般用于遗留系统改造，页面太多，原来也没有结构化设计，实现的情况下，sitemesh 或许是条路。 新的系统不应该用sitemesh, 考虑 tiles 等。 |
| 返回顶楼 | |
|
发表时间：2010-07-18
最后修改：2010-07-18
不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局. 其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends 性能也比sitemesh好很多. |
| 返回顶楼 | |
|
发表时间：2010-07-19
超级潜水员 写道 不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局. 其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends 性能也比sitemesh好很多. 这个思路的确不错,很像rails里面的模板系统,不过看了一下它的源码, 各个子页面渲染后也是存在request的一个attribute里面, 最后被父页面替换,这样如果一个页面很大的话应该也会跟sitemesh一样占用很多内存吧, 不过它的性能应该比sitemesh高,因为它不需要解析子页面 |
| 返回顶楼 | |
|
发表时间：2010-07-19
最后修改：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性能高. |
| 返回顶楼 | |
|
发表时间：2010-07-19
超级潜水员 写道 不推荐使用tiles.
请问, 不推荐 tiles 的原因是什么? |
| 返回顶楼 | |
|
发表时间：2010-07-19
sitemesh解析html性能应该是没问题的
他们为了提供解析性能是手写的一个html parser playframework到是用的继承思路，不过由于是groovy的，性能没有rapid的好 不过有人另外实现了一个japid |
| 返回顶楼 | |
|
发表时间：2010-07-19
用sitemesh就是用空间换时间，也就是用大内存去换取性能，不过现在内存便宜，考虑到sitemesh对开发带来的便利性，还是非常值得的
|
| 返回顶楼 | |
