简体   繁体   English

ASP.NET MVC如何花费10秒钟以上的时间(第一次)加载空白Controller?

[英]How can ASP.NET MVC takes more than 10 Seconds to load (for the first time) a blank Controller?

I'm managing an ASP.NET MVC application which use (basically) .NET MVC and Entity Framework . 我正在管理一个(基本上)使用.NET MVCEntity FrameworkASP.NET MVC应用程序。 I notice that every time I Publish the website, it takes very long time (around 10-15 seconds) every time I load (for the first time) each Controller/Action . 我注意到,每次发布网站时,每次(首次)加载每个Controller/Action都花费很长时间(大约10-15秒)。

I thought it was some Entity problem, so I've created a blank TestController/Index and place a simple View code: 我以为是Entity问题,所以我创建了一个空白的TestController/Index并放置了一个简单的View代码:

// Controller
public class TestController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

// View Index.cshtml
test page controller Page generated in @((DateTime.UtcNow - HttpContext.Current.Timestamp.ToUniversalTime()).TotalSeconds.ToString("F4")) seconds   

Than I publish the website using Visual Studio ( FTP mode). 比我使用Visual Studio发布网站( FTP模式)。

Once published, I call from browser a separate/generic/public page ( Home/Index for example), trying to "load/build" the app for the first time; 发布后,我从浏览器中调用一个单独的/通用/公共页面(例如, Home/Index ),尝试首次“加载/构建”该应用; it will indeed require a bit of time, due to build and such, but that's fine). 由于构建等原因,确实需要一些时间,但这很好)。

Now: when I try to load that empty TestController , it still takes lots of time: 现在:当我尝试加载空的TestController ,它仍然需要很多时间:

在此处输入图片说明

How can this be possible? 这怎么可能? Does it compile each single controller separately? 它是否分别编译每个控制器? So every time I load a new controller (after publish the website or retart the pool) it will take that amount of time? 因此,每次我加载新的控制器(在发布网站或重新分配池之后),都​​会花费那么多时间吗? I guess I'm wrong... 我想我错了...

The second time I load it (and the following) is very faster: 我第二次加载它(及以下)的速度更快:

在此处输入图片说明

How can I fix this? 我怎样才能解决这个问题? Where could it be the problem? 问题可能出在哪里?

Note apart - this is my Global.asax , which shouldn't engrave: 请注意-这是我的Global.asax ,不应刻上:

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }

    protected void Application_PostAuthenticateRequest(Object sender, EventArgs e)
    {
        HttpCookie authCookie = Request.Cookies["CookieFA"];
        if (authCookie != null)
        {
            FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);

            CustomPrincipal principal = new CustomPrincipal(authTicket.Name);
            CustomPrincipalSerializeModel userSerializeModel = JsonConvert.DeserializeObject<CustomPrincipalSerializeModel>(authTicket.UserData);
            principal.UserID = userSerializeModel.ID;
            principal.FirstName = userSerializeModel.FirstName;
            principal.LastName = userSerializeModel.LastName;
            principal.Roles = userSerializeModel.RoleName.ToArray<string>();

            HttpContext.Current.User = principal;
        }
    }
}

This happen because .NET build the view related with your action in the first request, it's the cause for the first request is slowly and the next ones faster. 发生这种情况是因为.NET在第一个请求中构建了与您的操作相关的视图,这是第一个请求缓慢的原因,而下一个请求的速度更快。 To improve it, you can build the views together with the application, exists some extensions that can do it for you as: 为了改进它,您可以将视图与应用程序一起构建,存在一些扩展可以为您完成这些操作,例如:

https://www.nuget.org/packages/RazorGenerator.Mvc/ https://www.nuget.org/packages/RazorGenerator.MsBuild/ https://www.nuget.org/packages/RazorGenerator.Mvc/ https://www.nuget.org/packages/RazorGenerator.MsBuild/

You can read more in the RazorGenerator GitHub page about how to use these extension. 您可以在RazorGenerator GitHub页面上阅读更多有关如何使用这些扩展的信息。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM