ASP.NET MVC URL生成性能

ASP.NET MVC的一點基準。的ViewPage代碼：ASP.NET MVC URL生成性能

public string Bechmark(Func<string> url) 
    { 
     var s = new Stopwatch(); 
     var n = 1000; 

     s.Reset(); 
     s.Start(); 
     for (int i = 0; i < n; i++) 
     { 
      var u = url(); 
     } 
     s.Stop(); 
     return s.ElapsedMilliseconds + " ms, " + ((s.ElapsedMilliseconds)/(float)n) + " ms per link<br/>"; 
    }

查看代碼：

<%= Bechmark(() => Url.Action("Login", "Account")) %> 

<%= Bechmark(() => Url.Action("Login", "Account", new {username="bla", password="bla2", returnurl="blabla32", rememberme=false})) %> 

<%= Bechmark(() => Html.BuildUrlFromExpression<AccountController>(a=>a.ChangePassword("bla", "bla", "ya"))) %>

上與ASP.NET MVC Beta版默認的新項目模板典型的酷睿2筆記本上運行這會產生以下結果：

38 ms，每個鏈接0,038 ms

120 ms，每個鏈接0,12 ms

54毫秒，每鏈路

用約10個控制器具有所有在所有周圍100的方法和30個路由表條目運行在生產項目相同的基準0054毫秒，則性能降低用於基於表達式的方法：

31毫秒，0031毫秒每鏈路

112毫秒，0112毫秒每鏈路

450毫秒，每鏈路
.45毫秒

我們使用這種方法很多（可維護性）和做一些性能基準測試，這大大降低了網站的性能 - 網頁很快包含大約30個或更多的這樣的鏈接，這意味着一個單一的額外開銷10毫秒頁。即使每個URL有0.112ms，純CPU的開銷也只有4ms。

應當指出的是，MVC第三個預覽版和Beta之間的所有三個URL生成調用（昨天發佈）的性能得到了由5

堆棧溢出的因素是提高據稱由同一框架內，如何供電你們有沒有解決這個縮放問題？首頁的自由緩存（大量鏈接）和預渲染的控件？

在ASP.NET MVC中的任何其他生產網站與性能問題或一些好的提示？

來源

2008-10-17 rudib

這裏是一個你可能會覺得有用的鏈接：http://blog.whiletrue.com/2009/04/aspnet-mvc-performance/ – Nik 2009-05-16 13:37:46

@Nik：其實我是那個演講的作者，很好...是的。:) – rudib 2009-05-18 19:46:13

緩存鏈接對於團隊來說可能是一個很好的建議，因爲它們在整個過程中不會改變（對於大多數應用程序來說）。

在開始以可配置的形式（例如web.config或數據庫）定義路由之前，您必須縮小一點。

我懷疑中間示例中的大部分延遲是自動轉換爲字典的匿名類型。緩存網址在這裏無法幫助你/你仍然需要反映這種類型。

與此同時，您可以爲一些基於字典的鏈接創建自己的幫助器方法，以便接受所需的確切輸入。然後你可以自己處理緩存。

來源

2008-10-17 13:58:01

好，在空白模板項目另外兩個指標：

<%= Bechmark(() => Url.Action("Login", "Account", new Dictionary<string, object> {{"username", "bla"}, {"password", "bla2"}, {"returnurl", "blabla32"}, {"rememberme", "false"}})) %> 

<%= Bechmark(() => Url.Action("Login", "Account", new RouteValueDictionary(new Dictionary<string, object> {{"username", "bla"}, {"password", "bla2"}, {"returnurl", "blabla32"}, {"rememberme", "false"}}))) %>

結果：

71毫秒，0.071毫秒每個環節

35毫秒，每個鏈路
0035毫秒

用更方便的代碼實現更好的性能。太糟糕了。

來源

2008-10-17 14:15:11 rudib

緩存鏈接很可能是爲球隊好建議，因爲他們不會在過程的生活變化（對於大多數應用反正）。

如何緩存鏈接，據我所知，你不能這樣做，因爲你需要緩存執行的方法，這是在路由解決後發生的，這是緩慢的部分。

來源

2008-10-17 17:43:58 bashmohandes

我在MS論壇上問過這個問題，它從MS MVC開發人員那裏得到了答案。

The post

答案

從MVC預覽2至最近發表的MVC的測試從昨天開始已經出現了很大的變化，以路由。其中一些變化包括性能改進。這裏有一些技巧，使您的應用程序更高性能的URL生成：

使用命名路由。命名路線是路由的可選功能。這些名稱僅適用於URL生成 - 它們從不用於匹配傳入的URL。當您在生成URL時指定名稱時，我們只會嘗試匹配該路線。這意味着即使您指定的指定路線是路線表中的第100條路線，我們也會直接跳到該路線並嘗試匹配。

把你最常見的路線放在路由表的開始處。這將改善URL生成的性能以及處理傳入的URL。路由根據第一場比賽勝出的規則進行工作。如果第一場比賽是您的路線表中的第100條路線，那麼這意味着它必須嘗試99條其他路線並且它們都不匹配。

請勿使用URL生成。有些人喜歡它，有些人卻不喜歡。掌握有點棘手。如果您的網址非常具有動態性，那麼使用它非常好，但如果您的網址很少，可能會有點麻煩，也許您並不關心它們的樣子。

我最喜歡的選項＃1，因爲它的超級容易使用，這也使得URL生成從應用程序開發者的角度來看更具有確定性（也就是你！）。

來源

2008-10-19 14:02:10 CVertex

ASP.NET MVC URL生成性能

回答

相關問題