ASP.NET MVC URL生成性能 [英] ASP.NET MVC URL generation performance

问题描述

ASP.NET MVC的一些基准.查看代码:

A little benchmark with ASP.NET MVC. Viewpage code:

    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")) ) %>

在典型的Core2笔记本上使用ASP.NET MVC Beta在默认的新项目模板上运行此操作会产生以下结果:

Running this on a typical Core2 notebook on the default new project template with ASP.NET MVC Beta yields these results:

38毫秒，每个链接0,038毫秒

38 ms, 0,038 ms per link

120毫秒，每个链接0.12毫秒

120 ms, 0,12 ms per link

54毫秒，每个链接0,054毫秒

54 ms, 0,054 ms per link

在具有大约10个控制器的生产项目上运行相同的基准，这些控制器总共包含大约100种方法和30个路由表条目，对于基于表达式的方法，性能会大大降低:

Running the same benchmark on a production project with about 10 controllers that have all in all around 100 methods and 30 routing table entries, the performance degrades greatly for the expression-based method:

31毫秒，每个链接0,031毫秒

31 ms, 0,031 ms per link

112毫秒，每个链接0,112毫秒

112 ms, 0,112 ms per link

450毫秒，每个链接0.45毫秒

450 ms, 0,45 ms per link

我们使用了很多这种方法(可维护性)并进行了一些性能基准测试，这大大降低了网站的性能-页面很快包含大约30个或更多此类链接，这意味着单个页面需要10毫秒的额外开销.每个URL甚至0.112毫秒，大约就是纯CPU开销的4毫秒.

We use this method quite a lot (maintainability) and doing some performance benchmarking, this degrades the performance of the site greatly - pages quickly contain around 30 or more of such links, that means 10ms of additional overhead on a single page. Even 0.112ms per an URL is around 4ms of pure CPU overhead.

应注意，MVC Preview 3和Beta(昨天发布)之间的所有三个URL生成调用的性能提高了5倍.

It should be noted that performance of all the three URL generation calls between MVC Preview 3 and Beta (released yesterday) got improved by a factor of 5.

据说堆栈溢出是由相同的框架提供支持的，你们如何解决这个扩展问题?自由缓存首页(很多链接)和预呈现的控件?

Stack Overflow is supposedly powered by the same framework, how have you guys tackled this scaling problem? Liberal caching of the front page (lots of links) and pre-rendered controls?

ASP.NET MVC中的其他任何生产网站是否存在性能问题或一些不错的提示?

Any other production websites in ASP.NET MVC with performance issues or some good tips?

推荐答案

我在MS论坛上问了这个问题，该论坛从MS MVC开发人员那里得到了答案.

I asked this question on the MS forums, which got an answer from an MS MVC developer.

帖子

答案

从MVC Preview 2到最近发布的MVC Beta(从昨天开始)，路由有了很多更改.其中一些更改包括性能改进.以下是一些技巧，可以使URL生成在您的应用程序中更高效:

From MVC Preview 2 to the recently released MVC Beta from yesterday there have been a lot of changes to Routing. Some of those changes include performance improvements. Here are some tricks to make URL generation more performant in your application:

1. 使用命名路由.命名路由是路由的可选功能.名称仅适用于URL生成-从未用于匹配传入的URL.当您在生成网址时指定名称时，我们将仅尝试匹配该路由.这意味着，即使您指定的命名路由是路由表中的第100条路由，我们也将直接跳转至该路由并尝试进行匹配.

1. Use named routes. Named routes are an optional feature of routing. The names only apply to URL generation - they are never used for matching incoming URLs. When you specify a name when generating a URL we will only try to match that one route. This means that even if the named route you specified is the 100th route in the route table we'll jump straight to it and try to match.

将最常用的路由放在路由表的开头.这将提高URL生成以及处理传入URL的性能.路由基于第一个比赛获胜的规则进行.如果第一个匹配项是您的路由表中的第100条路由，则意味着它必须尝试其他99条路由，但没有一个匹配.

Put your most common routes at the beginning of the route table. This will improve performance of both URL generation as well as processing incoming URLs. Routing works based on the rule that the first match wins. If the first match is the 100th route in your route table, then that means it had to try 99 other routes and none of them matched.

不使用URL生成.有些人喜欢，有些人不喜欢.掌握起来有些棘手.如果您的网址非常动态，可以很好地使用它，但是当您开头的网址很少时，也许您根本不关心它们的外观，这可能会有些麻烦.

Don't use URL generation. Some people like it, some people don't. It's a bit tricky to master. It's nice to use if your URLs are very dynamic but it can be a bit of a hassle when you have very few URLs to begin with and perhaps you don't care about exactly what they look like.

我最喜欢的选项是#1，因为它非常易于使用，而且从应用程序开发人员的角度来看，URL的确定性更高(就是您！).

My favorite option is #1 since it's super easy to use and it also makes URL generation more deterministic from the app developer's perspective (that's you!).

这篇关于ASP.NET MVC URL生成性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！