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

測試環(huán)境：CPU：酷睿2 T5750，內(nèi)存：DDR2-667 2G，Web容器：Tomcat6.0，最大線程數(shù)設置為1000，操作系統(tǒng)：WinXP-sp32011大智慧下載

測試步驟：搭建6個Web工程，如下：

1.純JSP:不包含任何MVC框架，只有一個測試用的JSP頁面。

2.struts1：包含一個Action，不做任何邏輯處理，直接轉(zhuǎn)發(fā)到一個JSP頁面

3.struts2 JSP：不包含Action，只包含測試JSP頁面，直接訪問該頁面。

4.struts2 單例Action：采用Spring來管理Struts2的Action實例，并配置成單例模式。

5.struts2 多例Action：采用Spring來管理Struts2的Action實例，并配置成單例模式。

6.SpringMVC3：采用Spring來管理Controller實例，包含一個Controller，不做邏輯處理，收到請求后，直接返回到一個JSP頁面。

測試結(jié)果：

說明：以上測試雖不是非常的精確，但基本能說明一定的問題。每個JSP頁面和Action都不包含任何的業(yè)務邏輯代碼，只是請求轉(zhuǎn)發(fā)。每輪測試取三次總時間的平均值。所有工程的測試均全部完成并正常處理請求，沒有請求拒絕情況發(fā)生。

結(jié)論：

1.純JSP的性能應該最高，這不難理解，JSP被編譯成Servlet后，沒有任何多余的功能，收到請求后直接處理。（這也驗證一句經(jīng)典的話：越原始效率就越高。）債務追討

2.struts1的性能是僅次于純JSP的，由于struts1采用單例Action模式，且本身的封裝相比struts2應該說簡單很多，雖然開發(fā)效率不如struts2，但已經(jīng)過多年的實踐考驗，性能穩(wěn)定高效。

3.相比來說struts2的性能就比較差了，這不難理解，struts2之所以開發(fā)方便，是由于采用值棧、OGNL表達式、攔截器等技術(shù)對請求參 數(shù)的映射和返回結(jié)果進行了處理，另外還采用大量的標簽庫等，這些都無疑增加了處理的時間。因此降低了效率。在我們實際的項目中，我測試本地工程訪問每秒處 理請求數(shù)只能達到35左右，應該說還有不少可優(yōu)化的空間。

4.很多人認為struts2性能差是因為它的多例Action模式導致的，但我們采用spring管理struts2的Action，并設置按單 例方式生成Action實例后，發(fā)現(xiàn)其性能有所提高，但并不是很明顯。由此可見，多例Action模式并不是struts2性能瓶頸所在。另外，我們在 struts2中采用JSP方式訪問，發(fā)現(xiàn)其性能依舊和沒有采用任何MVC框架的純JSP之間存在好幾倍的差距，這又從另一個側(cè)面證實了我們剛才得出結(jié) 論，struts2性能的瓶頸不在于它的多例Action模式。       

5.SpringMVC3的性能略遜于struts1，但基本是同級別的，這讓人眼前一亮，springMVC有著不比struts2差的開發(fā)效率 和解耦度，但性能卻是struts2的好幾倍，這讓我們灰常振奮，SpringMVC無疑又是項目開發(fā)的一個好的選擇。唯一的問題就是，目前國內(nèi)使用面還 不太多，各方面的參考資料相對較少，上手的話可能要稍微難點。