ASP.NET 3種編譯模式壓力測試

前段時間，由於工作需要，對ASP.NET的3種編譯模式進行了簡單的LoadRunner壓力測試。包括ASP.NET WebSite網站動態編譯，WebSite網站預發布，以及WebApplication先行編譯release三種模式在並發使用者數200,500,100的三種情況下響應總時間均值，First buffer Time均值，CPU峰值。

為了盡量讓資料客觀、公正，又能讓測試數值不至於“紮堆”，我選擇了我們公司一個中型項目，把比較有代表性，並且相對業務複雜的首頁分別做成websitecode(動態編譯)、WebsiteRelease（預發布）和Webapplication（Release發布）三種項目，在公司相對比較獨立的測試環境中，用LoadRunner進行測試。由於時間關係，只整理了並發使用者數200,500,100的三種情況下的資料，可能並不能完全精準的說明什麼，只希望能給出某些啟示。

以下給出詳細資料

 

響應總時間均值

 

個人分析：從以上資料（圖表）可以很明顯看出，Website預分布方式在隨著並發使用者數量增加的情況下，服務總時間是有相對優勢的，平均是1秒左右：）當然在並發使用者200及以下，它跟webapplication方式沒有明顯區別，但Website動態編譯卻表現最差：（

  

First buffer Time均值

個人分析：Frist Buffer Time是我個人最關注的資料，因不在網路傳輸中有這樣那樣的不可控和不可預計的因素，所以這個時間最能客觀描述三種編譯模式的首次訪問時間優劣。以上面的資料和圖片中，我們很明顯看出Website是那麼的表現“異常”，當然這個我們不難想像。但讓我們“小意外”的是，大概在並發800以下，webapplication居然比website預發布的模式稍差：（

CPU峰值

個人分析：以上是瞬時CPU峰值，可以看出Website預發布方式的CPU最讓人揪心，其次是是Webaplication，最次是website動態編譯，而且website動態編譯在並發500以下，貌似沒有CPU的上升。

 

總結：自從最早接觸.net1.1以來，就一直用webapplication方式進行項目架構、設計，並習慣於把所有的CS打包到一個統一的DLL中。自從vs2005發布，做了一看多的website項目，無奈中用websiterelease的方式開發一年，而且隨之發現網站的隨時更新不可能每天用websiterelease發布，於是還用了一個好像名叫web develpment外掛程式工具，還好，沒有多久vs2005sp1替代了這個東西。隨之，也於website動態網站告以byebye。

跟很多開發前輩、兄弟一樣，本人對website動態編譯有種說不出來的打從心底裡面出來的莫名的抵制，畢竟它的“寬鬆式”專案管理理念讓本來就要嚴謹的項目開發變得好像不那麼靠譜，就想某個東西被卡在喉嚨！！但往往跟它PK的時候，總是說不出一個所以然。而且很多時候唯一能說服人的，就是編譯！今天通過以上資料，我們可以看出，其實無論什麼編譯模式，都有優有劣。

按我們公司測試部資料換算，賬大概是這樣算的，1000並發使用者的情況，大約是每天1億的PV，如果你的公司團隊，技術人員是20以上，PV是1000萬級的，毫無疑問，請選擇Webapplication，無論是它cpu的表現穩定性，瞬時響應穩定性。但如果你公司是3人以下技術人員，每天訪問10萬以上，website動態編譯是不錯的選擇。

 

南曉斌

2010.11.1