用测试来对比分析struts与springMVC的性能

mlw2000

浏览: 37357 次
性别:
来自: 深圳

最近访客更多访客>>

yuanyu113

haining128

蓝天飞鹰

konoha

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

Struts 软件测试 Tomcat Spring ITeye

1 前言

    这篇帖子应该发布在一个月前，因为iteye的发帖机制调整，问答积分的限制把俺堵在了大门外。
    写这篇文章是因为个人一直存在一些疑问：
    a. struts的性能到底怎么样？
    b. springMVC相比struts高多少？
    我这个人呢，有个缺点————总是要看到数据才甘心。可能是专家们被忽悠太多次，以至于心里有阴影了，嘿嘿。

2 测试准备

    2.1 测试工具：apache ab（简单实用，load runner就不搞了）
    2.1 系统环境：OS: Red Hat EL 5(64bit), CPU: Intel Xeon E5310 1.60GHz(单颗4核cpu), Mem: 4G
    2.2 软件环境：Tomcat 6.0.23, jdk 1.6.0_23, Struts2.2.3测试用war包, SpingMVC3.0.5测试用war包。
        2.2.1 tomcat jvm参数仅调整了堆大小为2G：JAVA_OPTS="$JAVA_OPTS -server -Xms2048M -Xmx2048M"
        2.2.2 测试的代码是从url简单传入1个参数，经过mvc的处理后渲染成html页面

3 测试过程

    3.1 部署两个war包到同一个tomcat下
    3.2 预热测试，先跑两次测试进行预热，已使结果更稳定
    3.3 通过浏览器请求拿到两个JSESSIONID以备使用，使用包含JSESSIONID的cookie，可以排除每次重新生成session造成的影响。
    3.4 测试并记录结果

4 测试结果

    4.1 ab参数 ab -n 10000 -c 10
            RPS每秒处理的请求数     TPR平均响应时间（毫秒）
            struts2.2.3 spring3.0.5     struts2.2.3 spring3.0.5
    第一次 4308     6439         2.321     1.553
    第二次 4150     5873         2.409     1.703
    第三次 3904     6389         2.561     1.565
    平均值 4121     6234         2.430     1.607

    4.2 ab参数 ab -n 10000 -c 10 -C JSESSIONID=XXXXXXXXXX
            RPS每秒处理的请求数     TPR平均响应时间（毫秒）
            struts2.2.3 spring3.0.5     struts2.2.3 spring3.0.5
    第一次 3803     6560         2.629     1.524
    第二次 4221     6965         2.369     1.436
    第三次 4180     6683         2.392     1.496
    平均值 4068     6736         2.463     1.485

5 结果分析

    5.1 从TPS上看，sping比struts吞吐量高66%
    5.2 从TPR上看，sping比struts响应速度高40%
    5.3 我们根据TPR和TPS的数据得出如下坚定的结论：“大家尽可能的用spring吧，springMVC比struts快50%以上!”

6 个人见解

    我们真的能从测试结果得出“sping比struts吞吐量高66%；响应速度高40%；springMVC比struts快50%以上”的结论吗？
    在整理好结果的第一个小时内，我也是这么认为的，但是我总觉得有不妥之处，以至于后来我推翻了自己之前的想法，原因其实很简单————我们选择了错误的测试用例。
    测试case只需要极其简单的运算，没有其他消耗系统资源的操作（比如db的存取）：
    http://127.0.0.1:8080/struts2/example/hello-world.action?name=name
    http://127.0.0.1:8080/spring3/example?name=name
    对于这么简单的运算，struts及sping约等于空转状态，这个测试能得出的结果是”springMVC与struts的空转响应时间是1.5和2.5毫秒“。
    由此得出：如果我们的系统本身的响应时间超出300毫秒，那么采用springMVC与struts的任一个框架，对性能的影响都在1%左右。对于一个不是要求响应在10毫秒以内的系统，采用springMVC或者struts不会有本质的性能区别。

7 结束语

欢迎直接指出问题.
ps：拒绝人身攻击(程度较轻可忽略).

test-data-jsessionid.zip (1.8 KB)
下载次数: 77

spring3.zip (6 KB)
下载次数: 102

struts2.zip (4.8 KB)
下载次数: 64

分享到：

部署解压缩的WAR文件夹到Jboss7 | 苏格拉底：寻找最大的麦穗

2011-06-08 12:09
浏览 5265
评论(31)
论坛回复 / 浏览 (31 / 21106)
分类:编程语言
查看更多

11 楼 skzr.org 2011-06-10

<div class="quote_title"> </div>
 
<ol>
<li>系统并发上限，不应当被struts2限制住了，因为到系统建设后期很多热点数据都会转移到内存或缓存中，这个时候热点页面的后台逻辑实际上是不耗时间的。</li>
<li>在易用性上spring3 mvc相比struts2来说更加好用。</li>
<li>在RESTful上和ajax中spring3 mvc比struts2更好用。</li>
</ol>
 我单独测试jsp+el正在我的笔记本上一个table显示最高可以到1.5w/s 测试时特别注意网络的IO极有可能成为最终瓶颈，使用ajax是不错的选择。 实际上对于高负载的系统，优化到后面，mvc效率对系统并发也有很大的影响。
 
最终抛弃struts2是因为使用struts1过来的，后来搞struts2,感觉很多东西都是多余的，再后来解除spring3 mvc就被其简单易用迷住了
套用一句话：谁用谁知道！
struts1经历过7、8个大系统，struts2经历过2个大系统，spring3 mvc目前还没有。
感觉struts2比struts1设计好，不过却没有struts1易用阿,效率上也没有struts1好，很多时候struts2的哪些设计和考虑基本上在开发中都用不上。
后来RESTful和ajax后，spring3 mvc太棒了。

10 楼 downpour 2011-06-09

mlw2000 写道

skzr.org 写道

实际上你这个分析考察的不再是mvc的性能了，包括了后台的sql执行效率。

第一：
其实我的结论很简单：

“对于一个普通的DELL PC服务器(1.6G hz cpu)来说，采用struts会额外消耗2.5ms的响应时间，采用spring会额外消耗1.5ms的响应时间”。

第二：
这样测试的结果可以作为我们系统技术选型的依据：

假如我们容许3%的性能损失，那么100毫秒以上的业务请求都可以随意使用MVC框架，剩余的关键请求可以采用servlet来处理。

第三：
单单就我测试的硬件环境来看，struts 吞吐量达到4000，spring达到6500；达到这个值的前提是“在action或者controller中几乎完全省略了业务逻辑”。考虑到在95%的情况下，系统的响应时间要求基本上都会超过100毫秒（对于10ms级的应用系统讨论就不需要讨论这个问题了），所以从这个意义上来说，我刚开始的测试可以说是是走入了一个误区，不过弄拙成巧，测试结果反过来从另一个角度解答了我们的疑问。

PS：对于关心servlet性能的同学，我也同期也测试了纯jsp+el表达式的实现，测试吞吐量在7000~8500之间漂移比较大，个人以我那台服务的硬件觉得8000已经是极限了，漂移也比较正常。

个人见解：
关键节点用servlet，其余完全可以MVC，至于选择哪个完全看爱好。

请问什么是关键节点？关键节点就没有业务逻辑了？

9 楼 mlw2000 2011-06-09

<div class="quote_title">skzr.org 写道</div>
<div class="quote_div">实际上你这个分析考察的不再是mvc的性能了，包括了后台的sql执行效率。
 
</div>
 
<h4>第一：</h4>
其实我的结论很简单：
“对于一个普通的DELL PC服务器(1.6G hz cpu)来说，采用struts会额外消耗2.5ms的响应时间，采用spring会额外消耗1.5ms的响应时间”。
 
<h4>第二：</h4>
这样测试的结果可以作为我们系统技术选型的依据：
假如我们容许3%的性能损失，那么100毫秒以上的业务请求都可以随意使用MVC框架，剩余的关键请求可以采用servlet来处理。
 
<h4>第三：</h4>
单单就我测试的硬件环境来看，struts 吞吐量达到4000，spring达到6500；达到这个值的前提是“在action或者controller中几乎完全省略了业务逻辑”。考虑到在95%的情况下，系统的响应时间要求基本上都会超过100毫秒（对于10ms级的应用系统讨论就不需要讨论这个问题了），所以从这个意义上来说，我刚开始的测试可以说是是走入了一个误区，不过弄拙成巧，测试结果反过来从另一个角度解答了我们的疑问。
 
PS：对于关心servlet性能的同学，我也同期也测试了纯jsp+el表达式的实现，测试吞吐量在7000~8500之间漂移比较大，个人以我那台服务的硬件觉得8000已经是极限了，漂移也比较正常。
 
<h4>个人见解：</h4>
关键节点用servlet，其余完全可以MVC，至于选择哪个完全看爱好。

8 楼 itstarting 2011-06-09

楼主的冷静期分析的不错，否则很多人又要被忽悠一次，还不知道为什么被忽悠的，所以还是欣赏你的审慎

我个人是用Spring mvc的，简单好用。

不过这种框架裸奔性质的测试意义不大，MVC需要考虑的东西还很多，比如表单绑定/转换、校验、VIEW端的“合理”支持、国际化、页面流、RESTFUL……我是数不完，但真的得面对

你不信你测试一下，裸的servlet加上简单的包装，性能可能比这些都好——毕竟spring、struts也必须站在servlet的肩膀上，而servlet又常常是线程不安全的

7 楼 kingkan 2011-06-09

downpour 写道

lnaigg 写道

如果没有高并发的场景，MVC的性能对整个系统影响应该是比较小的。

随着并发量增长，MVC的效率要求会有所提高，但不会是重点。

个人认为，性能瓶颈有90%都出在持久层。

MVC的选型一般会从架构方面、团队认可度方面考虑，不会从性能方面考虑。

所以楼主的分析是完全正确的。

我不知道为什么大家一直在纠结一个MVC框架的性能而不是它的可用度？我们引入一个框架的最终目的是什么？牺牲了哪些又得到了哪些好处？先明确这个问题，再来考虑这些不搭边的因素。

嗯，同感。看应用场景的侧重点在什么地方，分好轻重，再选择最适合的解决策略，而不是一味的投入那些框架。

6 楼 downpour 2011-06-09

lnaigg 写道

5 楼 lnaigg 2011-06-09

4 楼 hardPass 2011-06-09

楼主，你要不要加上纯servlet的测试？
或者再加上Struts1,struts1会不会比struts2更快点？

3 楼 downpour 2011-06-09

引用

需求：

1. 服务器连接的需求：

写道
一个实际场景：一个城市缴费系统，大约有146个营业厅，每个营业厅大约3台缴费机。实际上还有其他人也会通过这个系统查询数据。
系统要求，页面响应非查询类<500ms，查询类<3s.
缴费时，可能发生集中缴费，如月中，某个休息日或中午。
假设，每个营业厅同时有2台机器在访问系统，那么就是146个访问，按照1个页面需要连接服务器20次计算，大约1s请求=146*2*20=5840

 从这里看到struts2的提升空间不大。如果是单台tomcat+sturts2，在忙时基本无法满足需求了。

 这时struts2大大限制了系统能承载的请求上限。

2. 优化——说白了就是不断减少页面的响应时间，从而提高并发

a. mvc页面：因为后台操作一般可能需要耗时300ms，而采用spring mvc带来性能的提升仅仅只有几个ms,这个只能说明mvc部分的优化重点是后台操作

 优化: 页面静态化、页面缓存、后台数据缓存，等等可以把时间大大缩减到100ms以内

b. 静态连接：显示一个mvc页面往往需要10\20个静态连接支持，这些虽然时间很短基本上都是10ms以内，胜在数量众多。

 优化：多台服务器去承载

 实际上分析iteye发现，主页和静态资源哪怕是图片等使用了304的都基本在100ms左右响应的.

想象下如果我们做的系统所有数据都在内存中，那么对于这样的系统struts2 mvc将会极大的阻碍系统并发上限，当然我们可以认为jsp的上限并发我们是无法达到的。

对于你这种莫名奇妙的分析和莫名奇妙的得出结论，实在是真的懒得反驳。

2 楼 amwiacel 2011-06-09

我承认结果，但我还是会用strust2

1 楼 skzr.org 2011-06-09

我的一个理由，见文章：<a style="color: #108ac6; text-decoration: underline;" href="http://skzr-org.iteye.com/blog/1037384">以下是我总结的为什么选择spring?</a>


我的机器配置：core2 P8400; 4G mem; ubuntu 10.10 64bit; jvm: -server -Xmx768M; tomcat: 7.02, 最大10线程
测试mvc也就是只测试单纯的controller跳转到view。结果struts2 mvc不到2K/s，spring3 mvc可以到5、6K/s
和你的测试结论应当说差不多
 
 
<div class="quote_title">mlw2000 写道</div>
<div class="quote_div">6 个人见解 我们真的能从测试结果得出“sping比struts吞吐量高66%；响应速度高40%；springMVC比struts快50%以上”的结论吗？ 在整理好结果的第一个小时内，我也是这么认为的，但是我总觉得有不妥之处，以至于后来我推翻了自己之前的想法，原因其实很简单————我们选择了错误的测试用例。 测试case只需要极其简单的运算，没有其他消耗系统资源的操作（比如db的存取）： http://127.0.0.1:8080/struts2/example/hello-world.action?name=name http://127.0.0.1:8080/spring3/example?name=name 对于这么简单的运算，struts及sping约等于空转状态，这个测试能得出的结果是”springMVC与struts的空转响应时间是1.5和2.5毫秒“。 由此得出：如果我们的系统本身的响应时间超出300毫秒，那么采用springMVC与struts的任一个框架，对性能的影响都在1%左右。对于一个不是要求响应在10毫秒以内的系统，采用springMVC或者struts不会有本质的性能区别。</div>
 
 实际上你这个分析考察的不再是mvc的性能了，包括了后台的sql执行效率。
我们打开iteye.com看看他的实际请求：
 <img src="http://dl.iteye.com/upload/attachment/495502/b849d6db-f8fc-3ca5-b4e0-dcbf47a5bf08.jpg" alt="">
一般一个页面在浏览器中显示是需要很多服务器资源支持的，如上：大约需要25个服务器连接才能完整的显示一个页面
显示页面的请求归类：
1. 动态页 mvc部分
2. 静态资源，哪怕是利用了客户端缓存也必然会存在一个304的连接用于判断资源是否发生更改。
无论是静态还是动态都会占用服务器连接的。
 
需求：
1. 服务器连接的需求：
 
<div class="quote_title"> 写道</div>
<div class="quote_div">一个实际场景：一个城市缴费系统，大约有146个营业厅，每个营业厅大约3台缴费机。实际上还有其他人也会通过这个系统查询数据。 系统要求，页面响应非查询类<500ms，查询类<3s. 缴费时，可能发生集中缴费，如月中，某个休息日或中午。 假设，每个营业厅同时有2台机器在访问系统，那么就是146个访问，按照1个页面需要连接服务器20次计算，大约1s请求=146*2*20=5840</div>
 从这里看到struts2的提升空间不大。如果是单台tomcat+sturts2，在忙时基本无法满足需求了。
 这时struts2大大限制了系统能承载的请求上限。
 
 2. 优化——说白了就是不断减少页面的响应时间，从而提高并发
 a. mvc页面：因为后台操作一般可能需要耗时300ms，而采用spring mvc带来性能的提升仅仅只有几个ms,这个只能说明mvc部分的优化重点是后台操作
 优化: 页面静态化、页面缓存、后台数据缓存，等等可以把时间大大缩减到100ms以内
 b. 静态连接：显示一个mvc页面往往需要10\20个静态连接支持，这些虽然时间很短基本上都是10ms以内，胜在数量众多。
 优化：多台服务器去承载
 实际上分析iteye发现，主页和静态资源哪怕是图片等使用了304的都基本在100ms左右响应的.
 
想象下如果我们做的系统所有数据都在内存中，那么对于这样的系统struts2 mvc将会极大的阻碍系统并发上限，当然我们可以认为jsp的上限并发我们是无法达到的。

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论