现在各种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页面。
通过测试
说明：以上测试虽不是非常的精确，但基本能说明一定的问题。每个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无疑又是项目开发的一个好的选择。唯一的问题就是，目前国内使用面还不太多，各方面的参考资料相对较少，上手的话可能要稍微难点。