現在各種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無疑又是項目開發的一個好的選擇。唯一的問題就是，目前國內使用面還不太多，各方面的參考資料相對較少，上手的話可能要稍微難點。