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都不包含任何的业务逻辑代码,只是请求转发。每轮测试取三次总时间的平均值。所有工程的测试均全部完成并正常处理请求,没有请求拒绝情况发生。springmvc常用标签
结论:
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无疑又是项目开发的一个好的选择。唯一的问题就是,目前国内使用面还不太多,各方面的参考资料相对较少,上手的话可能要稍微难点。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论