好吧，这是一个非常不科学的问题。提前抱歉。你们中的任何人使用 Windows azure（最好是 SQL Azure 数据库）在发布（或升级）代码后发现真正随机的性能问题？
我所看到的甚至可能在发布后长达 24 小时。这只是一般的延迟。http(s) 请求需要很长时间才能返回（30 秒 - 1 分钟），但下次调用相同的请求时可能会在几毫秒内返回。
看起来很随意。当我发布代码以 azure 什么都需要改变？负载平衡、DNS 缓存、IP 地址等...所有这些网络层更改的传播是否会导致我的问题？
顺便说一句，在几乎所有情况下，我都会升级登台环境，然后将 VIP 切换到生产环境。
这主要与您的网络角色有关吗？他们是否在运行 .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 有可以提供帮助的预热类。同样，还有更多可以确保您控制启动期间发生的事情，而不是启动发生时发生的事情。