现在各种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(每秒处理请求数)
JSP20002005.55 3.59 4.11 4.42 452.83
struts120002006.77 3.83 7.00 5.86 341.03
struts2 JSP200020025.20 26.30 24.11 25.20 79.35
struts2 单例Action200020028.36 27.59 27.69 27.88 71.74
struts2 多例Action200020031.31 31.97 39.56 34.28 58.34
SpringMVC320002007.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无疑又是项目开发的一个好的选择。唯一的问题就是，目前国内使用面还不太多，各方面的参考资料相对较少，上手的话可能要稍微难点。
【编辑推荐】
