asp.net - Azure Web App(ASP.NET MVC)每十分钟变冷一次，加载时间为+ 10-20s

Question

我对Azure Web应用程序有一个非常奇怪的问题，对此我感到非常沮丧。

我们体验到我们的应用在使用时非常快且响应迅速，但是，如果大约十分钟不使用它，它的启动就会非常冷(约10-20秒)。这种冷启动仅在涉及数据库时才发生。有点像我们发布网络应用程序时。

我们的尝试

使用Azure内部的Application Insights，我们每5分钟设置一次ping:



异常值总是由我的部署引起的(目前不使用部署插槽)。但是，此登录页面不会调用我们的数据库，因此在这些数据中我们看不到“冷”开始。

应用程序设置应稳定。我们的网络应用程序使用Always on托管在北欧:



我们只是将整个设置移到了新的资源组/应用程序服务计划中，以确保我们的问题与其他应用程序纠缠在一起。新的应用程序服务计划是Standard 1 small，应该没有问题。看看我们的消费情况，我并不担心，甚至可以尝试解决我们的问题后再做的较小的服务:



我们的SQL数据库也托管在北欧(十亿次检查位置，因为我之前犯过这个错误)。

就像应用程序服务一样，我们选择了“太大”的硬件来确保不会引起问题(标准S0:10个DTU)。使用率低得离谱:



我们确实使用了连续部署(Azure菜单内的Deployment options)，但是在查看部署时，它不应持续部署某些内容:



挫败感来自于应用程序在工作时的 super 响应能力。当“温暖”时，每个页面都将在几秒钟内加载，就像我的平均响应时间显示在我们的网络应用中一样:



但是，当我们(或我们的用户!)使用我们的应用程序时，这些数字完全是错误的。在这里，我们第一次遇到通常是+ 10-20秒的负载。

有谁有想法吗？有什么提示吗？你不知道我会多么感激。

编辑和更新1:

我决定设置更多测试。现在，我已经设法通过调用另一个页面来获取显示我们的问题的真实数据。具有讽刺意味的是，该页面没有调用数据库，因此尽管我认为这是数据库问题，但看起来却并非如此。在此处查看挑战(趋势持续+24小时)。

大约10秒到底有多稳定，这很奇怪。而且趋势似乎并不是每10-20分钟一次，而是接近每5分钟一次-它们之间的间隔完全相同:



编辑和更新2:

我一直在挖掘更多。事实证明，有一些非常有趣的见解:编辑1发出的“慢” 11秒 call 仅来自美国东部和一个端点(http://prntscr.com/jcv69w)，并且

我发现的最有趣的事情是:

应用程序本身没有任何缓存。我使用 Entity Framework ，假设使用了一些缓存，仅此而已。

我已登录到我们的应用程序，然后在Chrome浏览器中单击了。我发现，我已经访问过的页面正在显示即时信息(带有来自DB的数据)，但是如果我打开一个新页面，它将加载很慢。似乎我第一次打开页面时正在缓存某些实体。

然后，我尝试在新的浏览器中打开该应用程序。如果我打开了以前在Chrome中打开过的页面，则该页面会立即打开。如果我打开了一个我以前没有单击过的新页面，它将加载约10秒钟的时间。

我现在最好的猜测是，由于某种原因，我使用的 Entity Framework 给了问题。

编辑3:

刚刚添加了赏金，并设置了许多日志记录。我添加了MiniProfiler，但是在使其投入生产时遇到麻烦(仅在本地请求中显示)。

我还为Application_Start和Application_BeginRequest和Application_EndRequest添加了对global.asax的登录，以查看其中的一些信息和状态。即将更新调查结果。

编辑4:

因此，现在有了第一个有趣的数字。该应用程序尚未回收。 Application_Start仅被调用一次。

我可以通过登录EndRequest和BeginRequest看到时差。我可以看到有多个通话在这两个通话之间花费的时间超过+15秒...但是，当网站处于温暖状态时，根据页面的不同，通话时间约为0.5-2秒。因此，在请求的开始和结束之间发生了非常奇怪的事情。进一步调试!

编辑5:

得到了MiniProfiler的支持。这是缓慢加载(约15秒)的示例:



我的下一步是添加Entity Framework跟踪，甚至还有更多用于行调用的行。我正在数据库上赚钱!

编辑6:

冲绳，我错了。慢的是render方法-不是数据库!我不知道该如何调试...给Google!



编辑7:

是时候进行另一次更新了。状态是:什么都没有解决。

所以我尝试了很多事情:

1)我尝试禁用所有类型的缓存(Prevent Caching in ASP.NET MVC for specific actions using an attribute)，并且具有相同的行为。第一次加载？慢。下次加载？快速。等待5-10分钟，相同的行为无法解决。

2)我的startup.auth文件中有一些自定义内容，延迟了5分钟。已移除。没问题。

3)我使用自定义属性进行授权。我删除了。

4)我更新了 Entity Framework 的实现，以使其能够按请求运行

我真的很沮丧。我的下一步是:

A)尝试制作5-10个相同页面的版本(不带_layout，不带布局，不带数据库，不带数据库，不依赖项注入(inject)，不...所有这些东西)，所以看看是否可以找到一个模式。

B)尝试将主机移至虚拟机，以查看其是否解决了问题

编辑8-已添加新遗迹:

我现在添加了新遗物。以下是两个非常可怕的事情(我发现并重现了错误!):



在前端方面(New Relic的浏览器部分)，两次开始之间的间隔约为15秒:

http://prntscr.com/jevgeg与http://prntscr.com/jevgix之间没有任何区别。

Answer 1

我有几个可能的答案。

Entity Framework 的代码优先/数据库初始化:
如果您在迁移时使用代码优先设置，并可能在种子数据中使用，则每一项都会导致一些“热身”问题。

特别是，如果您不打算在应用启动时初始化数据库，那意味着您第一次访问数据库就是初始化数据库。

Entity Framework 版本:
Entity Framework 本身在5和6.x中也有很多性能改进，其中一些还与冷启动速度和热启动速度有关。

View 未预编译:
如果您在页面上的加载速度较慢(例如在部署后)，则新页面( View )的每个第一次命中都可以，然后进行后续加载就可以了。
这可能是因为页面未编译，如果是这样，我可以详细说明。

回收
听起来好像您在应用程序回收时遇到了这些问题，并且它不是自动初始化的(这就是为什么受到如此打击)，我在这些方面看到的最糟糕的性能问题通常与 Entity Framework 和预编译相关。但是两者都可以轻松修复。但是，确保应用程序“始终运行”并在回收后进行自我初始化还可以确保没有用户受到此冷门。

更新:
由于它与 View 相关，因此我可以提供一个解决方案，我发现它非常有用。
安装RazorGenerator.Mvc Nuget软件包。并将此引擎添加为第一个引擎将确保您使用编译 View 。

在App_Start中，您可以创建一个名为RazorGeneratorMvcStart.cs的文件，其内容如下:

using RazorGenerator.Mvc;

[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(MyNamespace.RazorGeneratorMvcStart), "Start")]

namespace MyNamespace {
    public static class RazorGeneratorMvcStart {
        public static void Start() {
            ViewEngines.Engines.Insert(0, new PrecompiledMvcEngine(typeof(RazorGeneratorMvcStart).Assembly));

            VirtualPathFactoryManager.RegisterVirtualPathFactory(engine);
        }
    }
}

对于喜欢实时替换 View 的用户， Razor 引擎甚至可以为 UsePhysicalViewsIfNewer设置参数。在这种情况下，除非已在文件夹中放置日期比已编译的.dll更新的 View ，否则它将使用预编译的版本。

这种方法应使用 View 解决性能问题。