ASP.NET MVC性能

Question

我發現一些野蠻的言論，ASP.NET MVC比ASP.NET WebForms快30倍。有什麼真正的性能差異，是否已經測量，性能有什麼好處。

這是爲了幫助我考慮從ASP.NET WebForms轉移到ASP.NET MVC。

Answer 1

我們還沒有進行必要的可擴展性和性能測試來得出任何結論。我認爲ScottGu可能一直在討論潛在的perf目標。隨着我們轉向Beta和RTM，我們將在內部進行更多的性能測試。然而，我不確定我們的政策是在發佈性能測試結果的時候。

在任何情況下，任何這種測試真的需要考慮實際應用...

Answer 2

Rick Strahl對What's Ailing ASP.NET Web Forms中的ASP.NET MVC性能有一些想法。

Answer 3

唯一具體的數字我可以找到它是從早期的ASP.NET MVC開發是在這個論壇線程：

http://forums.asp.net/p/1231621/2224136.aspx

羅布·康納利自己有點證實聲明ScottGu聲稱，ASP。 NET MVC可以每秒處理8000個請求。

也許傑夫和他的工作人員可以從他們的網站開發提供某種暗示。

Answer 4

它從2MB的有效載荷我的一個網頁下降，至20萬，僅僅通過消除視圖狀態，使之可以忍受編程工作與提交的輸出。

即使處理過程相同，單獨的大小也會大大提高每秒連接數和請求速度。

Answer 5

真的沒有辦法回答這個問題。 MVC默認使用Web窗體視圖引擎，並且可以配置爲使用任意數量的自定義視圖引擎，因此如果您想要進行性能比較，您必須更具體。

Answer 6

我的測試顯示MVC上的需求量在2x和7倍之間，但它取決於您如何構建Webforms應用程序。只要有「hello world」文字，無需任何服務器端控制，mvc的速度就會快30-50％左右。

Answer 7

對我來說，MVC中真正的「性能」改進是增加應用程序的可測表面。使用WebForms，有很多應用程序很難測試。使用MVC，可測試代碼的數量基本上翻了一番。基本上所有不容易測試的是生成佈局的代碼。您的所有業務邏輯和數據訪問邏輯（包括填充視圖中使用的實際數據的邏輯）現在都可用於測試。雖然我期望它的性能更高 - 頁面生命週期大大簡化，更適合於網頁編程 - 即使它相同或稍慢，從質量角度切換也是值得的。

Answer 8

我認爲這將是一個很難回答確切回答，因爲有太多依賴於A）你如何實現的WebForms應用程序，和B）您如何實現MVC應用程序。在他們的「原始」形式中，MVC可能比WebForms更快，但是多年的工具和經驗已經產生了構建快速WebForms應用程序的許多技術。我願意打賭，一個高級ASP。.NET開發人員可以生成一個可以與任何MVC應用程序的速度相媲美的WebForms應用程序，或者至少可以實現微不足道的差異。

真正difference- as @tvanfosson suggested - 是可測試性和清潔的SoC。如果提高性能是您最關心的問題，那麼我認爲這不是一個很好的理由在WebForms上發佈並開始在MVC中重新構建。至少在嘗試使用可用於優化WebForms的技術之前。

Answer 9

我認爲很多誰認爲的WebForms本質上是緩慢或資源密集型是放置怪錯了地方的人。當我被引入優化webforms應用程序時，有10次是9次，但是應用程序作者誤解視圖狀態的目的太多了。我並不是說視圖狀態是完美的或任何其他的，但是濫用它就太容易了，正是這種濫用導致了臃腫的視圖狀態領域。

本文無法幫助我理解這些濫用行爲。 http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx

爲了使MVC和我們需要確保這兩個應用程序是否正確使用結構的WebForms之間的有效比較。

Answer 10

大約一年前我開始在MVC工作，我受到了啓發，但沒有留下深刻的印象。

我不喜歡視圖狀態，並將其視爲ASP.NET中所有惡意的根源。這就是爲什麼我只是不使用它，並非常誠實地爲什麼會這樣呢？

我基本上採用了ASP.NET MVC框架概念，並以我自己的方式構建它。我改變了一些事情。我圍繞動態重新編譯構建了控制器包裝代碼或URL路由代碼。

現在，我會盡可能地說，根據您如何使用它，ASP.NET MVC應用程序將會更快。如果您完全放棄WebForms，那麼您將更快地改善ASP.NET生命週期，並且對象模型非常龐大。

當你寫你實例化一個軍隊...沒有等待，將參與您的視圖的渲染對象的軍團。這比在ASPX頁面中表達最小行爲的地方要慢。 （我不關心視圖引擎抽象，因爲在Visual Studio中對ASPX頁面的支持很好，但是我完全放棄了WebForms作爲一個概念，基本上任何ASP.NET框架由於代碼膨脹或無法更改連線我的應用程序的東西）。

我發現依靠的需要時發出特殊用途的對象和代碼動態重新編譯（System.Reflection.Emit）的方式。這段代碼的執行速度比反射快，但最初是通過反射服務構建的。這給了我的MVC風格的框架很好的表現，但也非常靜態類型。我不使用字符串和名稱/值對集合。相反，我的自定義編譯器服務將一個表單發佈重寫爲傳遞給引用類型的控制器操作。幕後有很多事情正在進行，但是這個代碼很快，比WebForms或MVC框架快得多。

另外，我不寫網址，我寫的是那些獲得翻譯成網址，後來知道調用哪個控制器動作lambda表達式。這不是特別快，但它擊敗了破損的URL。這就好像您擁有靜態類型的資源以及靜態類型的對象。靜態類型的Web應用程序？這就是我想要的！

我會鼓勵更多的人來嘗試一下。

Answer 11

我覺得這裏的問題是不管ASP速度多快。網絡MVC比舊的webforms，它不會有所作爲，因爲大部分時間都在數據庫中。大多數情況下，您的Web服務器將佔用0-10％的CPU使用量，僅等待數據庫服務器。除非你的網站上有大量的點擊，並且你的數據庫速度非常快，否則你可能不會注意到很大的不同。

Answer 12

Here從很久以前一些數字...

Answer 13

與Visual Studio中創建的項目。一個是mvc4模板，另一個是WebForm（tranditional）。 而當進行負載測試與WCAT，這是結果，

MVC4是比WebForms比較慢，有什麼想法？

MVC4

• 可以得到約11 RPS
• RPS是兩個雙CPU或4個CPU的服務器

的WebForms相當低（ aspx）

• 可以得到上述2500個RPS

• 的性能殺手已經發現它的MVC巴塔或RC的錯誤。 一旦我刪除Bundle的東西，性能會有所提高。現在最新版本解決了這個問題。

Answer 14

性能取決於你在做什麼...通常MVC主要是因爲視圖狀態不存在比asp.net更快，因爲MVC默認工作多與比回調回發。

如果您優化您的網頁表單頁面，您可以獲得與MVC相同的性能，但這將會花費大量工作量。

此外，他們是MVC（也爲Webform）的許多nugets，以幫助您提高網站性能，如組合和縮小您的CSS和JavaScript，分組您的圖像，並將它們用作精靈，等等。

網站的性能很大程度上取決於您的架構。一個清晰的關注點將爲您帶來更乾淨的代碼，並更好地瞭解如何提高性能。

你可以看看這個模板「Neos-SDI MVC Template」，這將爲你創建一個乾淨的架構，默認情況下有很多性能改進（檢查MvcTemplate網站）。

Answer 15

與公認的觀點相反，經過優化的webforms的使用完全殺死了原始性能方面的MVC。對於HTML服務的任務遠遠長於MVC，Webforms已經進行了高度優化。

指標可在http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

每一個比較MVC是在列表中的中等偏下/下 - 上的排名，而在中等偏上/上下排名優化的web表單的使用場所。

對這些指標的驗證非常軼事，但非常嚴重，www.microsoft.com由webforms而不是MVC提供。這裏有沒有人相信，如果它在經驗上更快，他們不會選擇MVC？

Answer 16

我做了一個小VSTS負載測試實驗中一些基本的代碼，發現ASP.NET MVC的響應時間相比，ASP.NET Web表單要快兩倍。以上是附圖的附圖。

你可以從這個CP文章http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

測試使用VSTS和Telerik的負載測試軟件下面的規格進行閱讀細節此負載測試實驗： -

用戶負荷25個用戶。

運行持續時間爲10分鐘。

機配置DELL 8 GB內存，酷睿i3

項目託管在IIS 8

項目使用MVC 5

假設網絡LAN連接創建。所以這個測試目前沒有考慮到網絡滯後。

瀏覽器在測試中選擇了Chrome和Internet Explorer。

在測試過程中對多個閱讀進行平均未知事件。在這篇文章中讀取7個讀數和所有讀數作爲讀數1，2等等。