当方法本身很快时，为什么MVC动作要花这么长时间才能返回

本文关键字：长时间 返回 方法 很快 MVC 为什么 | 更新日期: 2023-09-27 18:15:09

我有一个.net MVC动作，需要2000ms来完成。2000ms记录在IE开发工具网络选项卡中，瞥见，当我使用HttpModule来计时context_BeginRequest和context_EndRequest之间的差异。

然而，当我记录动作方法本身的计时时，所以从动作中的第一行代码到最后一行，时间只有300ms。我的最后一行代码生成视图，然后我记录时间，然后我返回视图-所以似乎即使视图生成在300ms内:

var view = View("~/Views/Home/Index.cshtml");
LogMethodTime("HomeController.Index", stopwatch);
return view;

我已经记录了相关控制器方法完成的时间-它们显示从构造函数到endeexecute的时间只需要534ms:

14:40:26,554 [13] INFO - Constructor
14:40:26,561 [13] INFO - OnAuthentication
14:40:26,608 [13] INFO - OnAuthentication
14:40:26,988 [13] INFO - OnActionExecuted
14:40:27,024 [13] INFO - OnResultExecuted
14:40:27,044 [13] INFO - EndExecuteCore
14:40:27,088 [13] INFO - EndExecute

asp.net管道中还有什么可以吞掉1700ms ?

我在本地通过IISExpress运行。

当方法本身很快时，为什么MVC动作要花这么长时间才能返回

请注意，大多数浏览器的开发工具的网络选项卡不提供所有正在进行的细粒度报告-特别是当您的web服务器允许浏览器保持连接活动以传输所需的所有数据时。提示，任何为生产用途设计的东西都可以。为此，您看到的内容如下:

  • 页面本身(当您测量时应该花费~500ms或更少)
  • 来自同一服务器的CSS样式表
  • 来自同一服务器的JavaScript文件
  • 来自同一服务器的图像

现代浏览器宁愿保持一个连接打开，并一次从同一主机(服务器)请求所有资源。这给连接增加了很多隐性成本。网络选项卡并不总是分解资源束的单个网络时间。

为了更好地了解MVC页面返回(完全转换)所花费的时间，您将需要使用JMeter或curl之类的工具。

通过在web.config中设置以下内容，我设法节省了500ms:

<compilation debug="false"

另外，通过添加更多的Trace语句，它强调了大部分时间发生在Application_BeginRequest和Controller构造函数之间——所以我创建了一个新问题来询问特定的细节。

Application_BeginRequest和MVC Controller构造函数之间的时间太长

相关文章：