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

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：拒绝人身攻击(程度较轻可忽略).

我的一个理由，见文章：以下是我总结的为什么选择spring?

我的机器配置：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

和你的测试结论应当说差不多

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

我们打开iteye.com看看他的实际请求：

一般一个页面在浏览器中显示是需要很多服务器资源支持的，如上：大约需要25个服务器连接才能完整的显示一个页面

显示页面的请求归类：

1. 动态页 mvc部分

2. 静态资源，哪怕是利用了客户端缓存也必然会存在一个304的连接用于判断资源是否发生更改。

无论是静态还是动态都会占用服务器连接的。

需求：

1. 服务器连接的需求：

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

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

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

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

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

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

      优化：多台服务器去承载

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

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

第一：

其实我的结论很简单：

“对于一个普通的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，至于选择哪个完全看爱好。