Java MVC框架性能比较
- by zvane
现在各种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无疑又是项目开发的一个好的选择。唯一的问题就是,目前国内使用面还不太多,各方面的参考资料相对较少,上手的话可能要稍微难点。