（轉）Java MVC框架性能比較

如今各類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頁面。

 

測試結果：

測試工程	請求數	併發數	總時間(s)	總時間(s)	總時間(s)	平均值(s)	Requests Per Second(每秒處理請求數)
JSP	2000	200	5.55	3.59	4.11	4.42	452.83
struts1	2000	200	6.77	3.83	7.00	5.86	341.03
struts2 JSP	2000	200	25.20	26.30	24.11	25.20	79.35
struts2 單例Action	2000	200	28.36	27.59	27.69	27.88	71.74
struts2 多例Action	2000	200	31.31	31.97	39.56	34.28	58.34
SpringMVC3	2000	200	7.16	7.50	4.27	6.31	317.09

 

說明：以上測試雖不是很是的精確，但基本能說明必定的問題。每一個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無疑又是項目開發的一個好的選擇。