好吧，这是一个非常不科学的问题。提前抱歉。你们中的任何人使用 Windows azure（最好是 SQL Azure 数据库）在发布（或升级）代码后发现真正随机的性能问题？
我看到的内容甚至可能在发布后长达 24 小时。这只是一般的延迟。 http(s) 请求需要很长时间才能返回（30 秒 - 1 分钟），但下次调用相同的请求时可能会在几毫秒内返回。
看起来很随意。当我发布代码以 azure 什么都需要改变？负载平衡、DNS 缓存、IP 地址等……所有这些网络层更改的传播是否会导致我的问题？
顺便说一句，在几乎所有情况下，我都会升级暂存环境，然后将 VIP 切换到生产环境。
【问题讨论】：
标签： asp.net-mvc iis azure warm-up
这主要与您的网络角色有关吗？他们是否在运行 .NET 代码？ （ASP.NET？、WCF？等）
如果是这样，您可能正在处理由于活动而被回收的 IIS 应用程序上的正常 .NET JIT 延迟。症状听起来就像您在现场有一个 ASP.NET 应用程序并且在一段时间内没有点击它。 IIS 工作线程被回收，并且运行时不会 JIT 编译您的应用程序，直到新的 HTTP 请求进入。这会造成第一个请求可能“永远”占用但接下来几分钟内进入的每个请求都为“即时”，正如您对代码所期望的那样。
这不是 Azure 特有的，但您可能正在处理与您在现场运行的环境不同的 IIS 环境（关于默认应用程序池回收设置/回收后的预热设置）。
根据建议编辑
如果您怀疑它与热身有关，有几个解决方案。
最好的（除非您需要）是管理根本原因，即 IIS 回收应用程序池。默认情况下，这发生在计时器或请求计数上（不确定 Azure 中的哪个）。您可以在 web.config 中使用 <recycling></recycling> 元素覆盖这种情况。 IIS.net 对这些设置有最好的描述。看看：
http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/recycling
看看是否有帮助。我建议您在没有被击中的时间段内（例如半夜）进行定时回收
另一种选择是确保网站的流量持续不断。使用某种投票软件。像 pingdom 这样的“正常运行时间/状态”监视器非常适合这个。这是一种黑客方法，但我以前在奇怪的场景中使用过它。 （不推荐）
如果由于特殊的启动要求（听起来您没有）而无法正常工作，则 IIS 有一个预热模块，而 C# 4.0 有可以提供帮助的预热类。同样，还有更多可以确保您控制在启动期间发生的事情，而不是在启动发生时发生的事情。
【讨论】：