c# - ASP.NET MVC URL 生成性能

Question

ASP.NET MVC 的一个小基准测试。查看页面代码:

    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 的默认新项目模板上的典型 Core2 笔记本上运行此程序会产生以下结果:

38 ms, 0,038 ms per link

120 ms, 0,12 ms per link

54 ms, 0,054 ms per link

在具有大约 10 个 Controller 的生产项目上运行相同的基准测试，这些 Controller 总共有大约 100 个方法和 30 个路由表条目，基于表达式的方法的性能大大降低:

31 ms, 0,031 ms per link

112 ms, 0,112 ms per link

450 ms, 0,45 ms per link

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

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

Stack Overflow 应该由相同的框架提供支持，你们是如何解决这个扩展问题的？首页(大量链接)和预呈现控件的自由缓存？

ASP.NET MVC 中的任何其他生产网站存在性能问题或一些好的提示？

Answer 1

我在 MS 论坛上问过这个问题，得到了一位 MS MVC 开发人员的回答。

The post

答案

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. 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.

2. 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.

3. 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.

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!).