Java MVC框架性能比較
現(xiàn)在各種MVC框架很多，各框架的優(yōu)缺點網(wǎng)絡上也有很多的參考文章，但介紹各框架性能方面差別的文章卻不多，本人在項目開發(fā)中，感覺到采用了struts2框架的項目訪問速度，明顯不如原來采用了struts1框架的項目快，帶著這些疑惑，我對各類MVC框架的做了一個簡單的性能分析比較，其結果應該說是基本符合預期的，可供大家參考。
測試環(huán)境：CPU：酷睿2 T5750，內存：DDR2-667 2G，Web容器：Tomcat6.0，***線程數(shù)設置為1000，操作系統(tǒng)：WinXP-sp3
測試步驟：搭建6個Web工程，如下：
1.純JSP:不包含任何MVC框架，只有一個測試用的JSP頁面。
2.struts1：包含一個Action，不做任何邏輯處理，直接轉發(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頁面。
測試結果：
測試工程請求數(shù)并發(fā)數(shù)總時間(s)總時間(s)總時間(s)平均值(s)Requests Per Second(每秒處理請求數(shù))
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都不包含任何的業(yè)務邏輯代碼，只是請求轉發(fā)。每輪測試取三次總時間的平均值。所有工程的測試均全部完成并正常處理請求，沒有請求拒絕情況發(fā)生。
結論：
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ù)只能達到35左右，應該說還有不少可優(yōu)化的空間。
4.很多人認為struts2性能差是因為它的多例Action模式導致的，但我們采用spring管理struts2的Action，并設置按單例方式生成Action實例后，發(fā)現(xiàn)其性能有所提高，但并不是很明顯。由此可見，多例Action模式并不是struts2性能瓶頸所在。另外，我們在struts2中采用JSP方式訪問，發(fā)現(xiàn)其性能依舊和沒有采用任何MVC框架的純JSP之間存在好幾倍的差距，這又從另一個側面證實了我們剛才得出結論，struts2性能的瓶頸不在于它的多例Action模式。
5.SpringMVC3的性能略遜于struts1，但基本是同級別的，這讓人眼前一亮，springMVC有著不比struts2差的開發(fā)效率和解耦度，但性能卻是struts2的好幾倍，這讓我們灰常振奮，SpringMVC無疑又是項目開發(fā)的一個好的選擇。唯一的問題就是，目前國內使用面還不太多，各方面的參考資料相對較少，上手的話可能要稍微難點。
【編輯推薦】
