您的位置: 首页  >  IT文章  >  sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）

sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）

分类: IT文章 • 2024-03-31 15:31:42
sitemesh性能测试结果比较惊艳（已经补上新的对比测试结果）
最近想在一个项目中使用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时的测试结果
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）
Visualvm的监控截图
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）
使用sitemesh时的测试结果
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）
Visualvm的监控截图
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）

从上面这些测试结果来看sitemesh对页面平均响应时间的影响还是比较小的，这个影响我觉得基本可以接受。
但是从Visualvm的监控结果让我非常的惊讶，使用sitemesh以后使得jvm的内存使用剧增，是未使用之前的10倍之多，与此同时cpu的使用率也是原来的3-4倍，由于内存使用量的剧增导致jvm的GC也频繁了许多。


新做的一轮测试，供大家参考
参考 rapid-framework的继承实现方式得到的测试结果
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）

参考老外搞的freemarker layouthttp://richardbarabe.wordpress.com/2009/03/19/freemarker-a-brief-example/ 实现方式得到的测试结果
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）

从上面这一轮测试可以看出来这两种方案的实现效果在页面响应时间上差不多，基本没有区别。内存波动也大致相同，唯一差别较大的是，使用rapid测试的场景cpu的使用率波动较频繁，而使用宏实现的装饰器cpu波动较少，CPU使用率相对较低。
此外使用rapid的场景中线程数的波动图较其他几个场景的波动要明显，不过在测试的时候我没有注意到这个情况，所以目前还不知道线程数量增多的原因。我怀疑是在这个场景下由于请求处理的稍微慢一些，导致VVM统计的活动线程数要高于其他场景。
希望以上这些测试结果对大家有参考意义。
1 楼 kimmking 2010-07-17  
hits少15%。
cpu是2-3倍。
内存大10几倍。

-----------
这个测试的tps小成这样，有实际意义吗？
另外建议监控用LoadRunner+istatd，别用vvm
2 楼 SeanHe 2010-07-17  
TPS应该和我故意在Freemarker里用了个双重循环的缘故，这么写我也是为了测试一下freemarker的性能
3 楼 srdrm 2010-07-18  
这个测试很有意义
sitemesh 一般用于遗留系统改造，页面太多，原来也没有结构化设计，实现的情况下，sitemesh 或许是条路。

新的系统不应该用sitemesh, 考虑 tiles 等。
4 楼 超级潜水员 2010-07-18  
不推荐使用tiles.
可以考虑使用rapid的 JSP继承, Freemarker继承, Velocity继承来实现布局.

其中的JSP继承介绍: http://code.google.com/p/rapid-framework/wiki/rapid_jsp_extends

性能也比sitemesh好很多.

5 楼 climber2002 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高,因为它不需要解析子页面
6 楼 超级潜水员 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性能高.
7 楼 iamjxc 2010-07-19  
超级潜水员 写道
不推荐使用tiles.

请问, 不推荐 tiles 的原因是什么?
8 楼 tapestry1122 2010-07-19  
sitemesh解析html性能应该是没问题的

他们为了提供解析性能是手写的一个html parser

playframework到是用的继承思路，不过由于是groovy的，性能没有rapid的好

不过有人另外实现了一个japid
9 楼 zelsa 2010-07-19  
用sitemesh就是用空间换时间，也就是用大内存去换取性能，不过现在内存便宜，考虑到sitemesh对开发带来的便利性，还是非常值得的
10 楼 SeanHe 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
11 楼 超级潜水员 2010-07-19  
十分期待LZ对这几种布局的性能测试比较.

sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）
12 楼 SeanHe 2010-07-20  
已经补上新的对比测试结果
推荐大家再看一下
13 楼 超级潜水员 2010-07-21  
照结果来看，freemarker-a-brief-example及rapid-framework在CPU消耗及内存消耗都比sitemesh低。

十分好的测试比较。
14 楼 badqiu 2010-07-21  
很好，以后rapid的布局可以有性能测试数据可查
15 楼 flashing 2010-07-22  
这是架构师需要权衡的部分了。
如果你做一个企业应用，页面并发不大，业务要求高的，sitemesh可以为你解决很多麻烦；但是你做互联网应用，页面并发大的，sitemesh可能性能就不够极致了。
得权衡的。
16 楼 zelsa 2010-07-22  
flashing 写道
这是架构师需要权衡的部分了。
如果你做一个企业应用，页面并发不大，业务要求高的，sitemesh可以为你解决很多麻烦；但是你做互联网应用，页面并发大的，sitemesh可能性能就不够极致了。
得权衡的。

互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微，性能一般不会出现在这一层的，所以不用太追求这一层的绝对性能
17 楼 flashing 2010-07-22  
zelsa 写道
flashing 写道
这是架构师需要权衡的部分了。
如果你做一个企业应用，页面并发不大，业务要求高的，sitemesh可以为你解决很多麻烦；但是你做互联网应用，页面并发大的，sitemesh可能性能就不够极致了。
得权衡的。

互联网应用也没有问题的, 一般一个Tomcat也就承载200左右的并发, 模板的性能再高也对整个app的并发提高微乎其微，性能一般不会出现在这一层的，所以不用太追求这一层的绝对性能

要这么说真没啥理由不用sitemesh。这玩意太好用了
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（&gt;5）年不需要调整布局</p>
<p>2. 装饰时页面混乱，不通业务页面需求不一样（做管理的，页面布局千奇百怪）--&gt;因为布局出问题时调试管理困难，牵连太多，每个都要测试</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>
19 楼 pond918 2011-03-30  
sitemesh3说是性能优化蛮多，3倍吞吐量，1/2内存消耗。楼主方便再跑一个对比测试吗
http://www.sitemesh.org/new-in-sitemesh3.html
sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果） sitemesh性能测试结果比较惊艳（已经补下新的对比测试结果）

相关推荐