如果我对 razor View 进行更改、重新编译或等待 15-20 分钟,则页面可能需要 3-20 秒才能在第一次点击时呈现。我知道 View 需要在更改后重新编译。我也知道应用程序将在一段时间不事件后卸载,但我认为这将是第一次点击时的一次性惩罚。但对我来说,它似乎适用于每一页。

以我的主页为例。根据 YSlow,它是一个“B”,有 15 个组件,重 250K(包括 MiniProfiler 的额外 jquery 引用)。从 MiniProfiler 我看到第一行(http://localhost:80)大约有 500 毫秒。我假设这包括 View 编译。但后来我看到 Find:Index 为 1200 毫秒。没有 SQL 调用。第一次点击的总加载时间约为 3000 毫秒,后续点击约为 40 毫秒。

在具有几个局部 View 的另一个页面上,父 View 需要 2400 毫秒才能“查找”,其中一个局部 View 需要 1000 毫秒才能找到。父 View 也需要 3200 毫秒来“渲染”。最大的影响是在第一行 (http://localhost:80/User/Dashboard),这是一个惊人的 7000 毫秒。该页面只有3个查询,总查询时间为100ms。总加载时间超过15000ms。随后的命中大约是 250 毫秒。

我们的设置是 ASP.Net MVC 3、Ninject、EF4.2、Razor View 引擎、ELMAH、NLog、Html5Boilerplate 和 MvcMiniProfiler。我创建了一个重复的项目并删除了 Ninject、ELMAH、NLog 和 MvcMiniProfiler。性能只是稍微快一点。我们在一个区域内有大约 15 个 Controller 和大约 40 个 View 。

这是正常的表现吗?当我们部署到 Azure 时,它​​甚至(自然地)比本地测试更糟糕。是否有改进建议?

编辑:
在 IIS/localhost 上编译后的第一次命中(在 Release模式下和编译 debug=false)可能需要大约 15 秒。在发布中运行的 Azure 部署具有更快的第一次命中,但仍在 5-10 秒的范围内。我尝试了 David Ebbo 的项目,但没有看到任何戏剧性的东西。

最佳答案

您是否经常部署此应用程序?如果是这样,那么我可以理解为什么第一次命中性能会受到关注。

我们经常部署,并创建了一个单独的项目来“预热”我们的部署。这是一个单元测试项目,它在部署后使用 WebDriver 在我们的应用程序中点击每个未编译的 View 。

基本上,您只需使用 WebDriver API 启动浏览器,然后 Navigate() 到需要编译的每个 URL。运行一次,部署很温暖。

此外,在 Azure 中,您可以关闭空闲超时,以便您的应用程序永远不会空闲。我们使用这个脚本:

%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00

...并在 Azure 部署期间运行它,如下所示:
  <Task commandLine="startup\disableTimeout.cmd" executionContext="elevated" taskType="simple" />

10-07 19:29
查看更多