asp.net Web form和asp.net MVC的一次效能比較別總以為asp.net mvc比asp.net web form好–web form的頁面也可以體積小巧關於大型asp

前次寫完《別總以為asp.net mvc比asp.net web form好--web form的頁面也可以體積小巧》後，收到不少評論。多數人不贊成本人提出的將viewstate放入session的做法。那麼就來實驗一下。搭建一個效能測試對比的平台。做一個應用，分別用asp.net web form來實現和用asp.net MVC來實現。兩個應用的頁面外觀是一致的。再搭建分布式的伺服器，反向 Proxy等。再加上一個效能測試用的http負載產生伺服器。

 

效能測試環境

 

如：

效能測試伺服器產生大量http請求來轟擊反向 Proxy的伺服器。反向 Proxy伺服器用Round Robin的演算法將這些請求導向到裡面的伺服器。裡面的伺服器返回http響應給反向 Proxy的伺服器，反向 Proxy伺服器再向效能測試伺服器響應。

Server1和Server2的配置：2GB RAM, 1個 2GHz CPU，300G 硬碟   Windows Server 2008 R2

反向 Proxy伺服器的配置: 1GB RAM,  1個 2GHz CPU, 80G硬碟   Ubuntu Linux 11.04，

效能測試伺服器配置：1GB RAM, 1 個 2GHz CPU, 80G硬碟   Windows XP

資料庫伺服器配置: 4GB RAM, 1 個 2G Hz CPU, 500G硬碟   Windows Server 2008 R2

也看到了，都是普通的機器。

反向 Proxy所用軟體 squid 3.1.4

Server1和Server2部署的是一樣的應用程式，即asp.net web form的應用程式和asp.net MVC的應用程式都部署到這兩台伺服器上。同時Server1和Server2訪問的是同一個資料庫。在應用程式裡做了一些web farm的配置。使得session儲存在sql server的ASPState資料庫中。Session資料就可在不同伺服器上進行浮動。http請求可由Server1和Server2任何一個來響應。當然這裡是只用了兩個IIS伺服器，可以加更多的。但是條件有限，只找得到兩台。這是最小的分布式的情境。如果有更多的話，整個系統的總體效能會更好一些。這裡的網路都是區域網路絡。

這裡說一下如何對比。這裡是用同一個應用程式的asp.net web form版本和asp.net MVC版本進行對比。從上面看到了，硬體都是一樣的。軟體這塊，劃分了常見的三層，BLL, DAL, 都是一樣的。唯一的不同是展示層的技術，一個用的是asp.net web form, 一個用的是asp.net MVC。其他的環節都是一樣的，只有這個展示層技術不同。對比的就是這個展示層技術。得說明的是，在asp.net web form中，採用了將viewstate放入session的方式。這樣做的目的，其實前文的時候已經在評論中說明過，是為了將web form的HTML頁面體積縮小，同時使viewstate和session一樣獲得在不同伺服器之間浮動的特性。

這裡是代碼的download：(用的最古老的ado.net，沒有採用TransactionScope，原因自己想。沒有採用aop，所以重複代碼好多，代碼產生器產生的，根本不費事、、、不跑題太遠，實在想說可以另寫文章）。

 

效能測試

 

 下面就說這個效能測試了。採用了loadrunner 8.1。先錄指令碼，再調試一下指令碼，這都是基本功了，不多說。準備好指令碼，一個指令碼是測試asp.net web form的，另一個指令碼是測試asp.net MVC的。之後將這些指令碼對著這個反向 Proxy伺服器轟擊。開始時是試探性的，只用10個使用者，沒有問題，再加，試了還沒有問題，再加，如此迴圈下去，直到，加壓到一定程度，這個效能測試中返回有失敗的case時，才停下。採用這種方式，試了很多，發現這些資料：

asp.net web form使用者為600時：

 

 

asp.net web form 使用者數為800時：

 

asp.net web form 使用者數為1200時：

 

asp.net web form 使用者數為1500時，才出現了失敗的case：

 

asp.net MVC 使用者數為600時，就已經開始有失敗的case：

  

asp.net mvc 使用者數為800時，失敗的case多了一點點：

 

 

asp.net mvc 使用者數為1200時，失敗的case又多了一些：

 

asp.net mvc 使用者數為1500時，失敗的case又多了一些：

 

完整的測試結果下載： download   包括loadrunner報告和loadrunner截屏。

 

結論

    經過這些對比。asp.net web form加上viewstate放入session中的安排，其效能並不輸給asp.net MVC。而且略有一點點佔優。還是之前說的觀點：只要沒有過度地使用viewstate或者session，合理地利用viewstate和session(如何合理利用，可以見《關於大型asp.net應用系統的架構—如何做到高效能高延展性》)，asp.net web form也可以在效能上表現比較好的，甚至有可能超過asp.net MVC的表現。所以不要輕易地下結論，也不要輕易地否定一個技術。當然了，這裡可能還是有些局限性，看到的是片面的。期望大家給予你們的真知灼見。

 

 

2012.07.10. 21:47增加內容

針對下面評論中的意見，做了一個web form未最佳化時的效能測試。之前做的所謂最佳化，就是將viewstate放到session裡了。見web form工程裡的那個BasePage類。如果讓所有aspx的後端類都繼承System.Web.UI.Page類，就去掉了這個所謂的最佳化。經過測試，發現即使什麼最佳化都沒有，web form還是要比asp.net mvc的效能好。一直壓到1400個使用者時才出現失敗的case.

 

可以看到，未加viewstate放入session特性，最大使用者為1400，加了viewstate放入session特性，最大使用者為1500，所以將viewstate放入session中後，所帶來的效能的改進似乎很有限。

當然還有評論建議都做最佳化後再對比。可以以後再來做。今天就暫時這樣了。謝謝

end of 20120710新增內容