（转）Java MVC框架性能比较

如今各类MVC框架不少，各框架的优缺点网络上也有不少的参考文章，但介绍各框架性能方面差异的文章却很少，本人在项目开发中，感受到采用了struts2框架的项目访问速度，明显不如原来采用了struts1框架的项目快，带着这些疑惑，我对各种MVC框架的作了一个简单的性能分析比较，其结果应该说是基本符合预期的，可供你们参考。

 

测试环境：CPU：酷睿2 T5750，内存：DDR2-667 2G，Web容器：Tomcat6.0，最大线程数设置为1000，操做系统：WinXP-sp3

 

测试步骤：搭建6个Web工程，以下：

1.纯JSP:不包含任何MVC框架，只有一个测试用的JSP页面。

2.struts1：包含一个Action，不作任何逻辑处理，直接转发到一个JSP页面

3.struts2 JSP：不包含Action，只包含测试JSP页面，直接访问该页面。

4.struts2 单例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。

5.struts2 多例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。

6.SpringMVC3：采用Spring来管理Controller实例，包含一个Controller，不作逻辑处理，收到请求后，直接返回到一个JSP页面。

 

测试结果：

测试工程	请求数	并发数	总时间(s)	总时间(s)	总时间(s)	平均值(s)	Requests Per Second(每秒处理请求数)
JSP	2000	200	5.55	3.59	4.11	4.42	452.83
struts1	2000	200	6.77	3.83	7.00	5.86	341.03
struts2 JSP	2000	200	25.20	26.30	24.11	25.20	79.35
struts2 单例Action	2000	200	28.36	27.59	27.69	27.88	71.74
struts2 多例Action	2000	200	31.31	31.97	39.56	34.28	58.34
SpringMVC3	2000	200	7.16	7.50	4.27	6.31	317.09

 

说明：以上测试虽不是很是的精确，但基本能说明必定的问题。每一个JSP页面和Action都不包含任何的业务逻辑代码，只是请求转发。每轮测试取三次总时间的平均值。全部工程的测试均所有完成并正常处理请求，没有请求拒绝状况发生。

结论：

1.纯JSP的性能应该最高，这不难理解，JSP被编译成Servlet后，没有任何多余的功能，收到请求后直接处理。（这也验证一句经典的话：越原始效率就越高。）

2.struts1的性能是仅次于纯JSP的，因为struts1采用单例Action模式，且自己的封装相比struts2应该说简单不少，虽然开发效率不如struts2，但已通过多年的实践考验，性能稳定高效。

 

3.相比来讲struts2的性能就比较差了，这不难理解，struts2之因此开发方便，是因为采用值栈、OGNL表达式、拦截器等技术对请求参数的映射和返回结果进行了处理，另外还采用大量的标签库等，这些都无疑增长了处理的时间。所以下降了效率。在咱们实际的项目中，我测试本地工程访问每秒处理请求数只能达到35左右，应该说还有很多可优化的空间。

 

4.不少人认为struts2性能差是由于它的多例Action模式致使的，但咱们采用spring管理struts2的Action，并设置按单例方式生成Action实例后，发现其性能有所提升，但并非很明显。因而可知，多例Action模式并非struts2性能瓶颈所在。另外，咱们在struts2中采用JSP方式访问，发现其性能依旧和没有采用任何MVC框架的纯JSP之间存在好几倍的差距，这又从另外一个侧面证明了咱们刚才得出结论，struts2性能的瓶颈不在于它的多例Action模式。       

       

5.SpringMVC3的性能略逊于struts1，但基本是同级别的，这让人眼前一亮，springMVC有着不比struts2差的开发效率和解耦度，但性能倒是struts2的好几倍，这让咱们灰常振奋，SpringMVC无疑又是项目开发的一个好的选择。