現在各種MVC框架很多，各框架的優缺點網絡上也有很多的參考文章，但介紹各框架性能方 面差別的文章卻不多，本人在項目開發中，感覺到采用了struts2框架的項目訪問速度，明顯不如原來采用了struts1框架的項目快，帶著這些疑惑， 我對各類MVC框架的做了一個簡單的性能分析比較，其結果應該說是基本符合預期的，可供大家參考。

測試環境：CPU：酷睿2 T5750，內存：DDR2-667 2G，Web容器：Tomcat6.0，最大線程數設置為1000，操作系統：WinXP-sp32011大智慧下載

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