将代码发布到 azure 的性能影响
好吧，这是一个非常不科学的问题。提前抱歉。在发布（或升级）代码后，使用 windows azure（最好是 SQL Azure 数据库）的任何人都会遇到真正随机的性能问题吗？
我所看到的甚至可能是发布后 24 小时内看到的。这只是一般的延迟。 http(s) 请求需要很长的时间才能返回（30 秒 - 1 分钟），但相同的请求在下次调用时可能会在几毫秒内返回。
看起来很随意。当我将代码发布到 azure 时，需要更改哪些内容？负载平衡、DNS 缓存、IP 地址等...所有这些网络层更改的传播是否会导致我的问题？
顺便说一句，几乎在所有情况下，我都会升级临时环境，然后将 VIP 切换到生产环境。
Ok, this is a pretty unscientific question. Sorry in advance. Any of you using windows azure (and preferably SQL Azure database) seeing really random performance issues after you publish (or upgrade) code?
What I'm seeing could even be up to 24 hours after the publish. It's just general latency. http(s) requests take an extreme amount of time to return (30sec - 1 min), but the same request could return in milliseconds the next time it's called.
It seems very random. When I publish code to azure what all needs to change? Load balancing, DNS cache, IP addresses, etc... could the propagation of all of these network layer changes be causing my issue?
BTW, in almost all cases I do an upgrade of the staging environment and then VIP swap to production.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这主要与您的网络角色有关吗？他们运行 .NET 代码吗？ （ASP.NET？、WCF？等）
如果是这样，您可能正在处理因活动而回收的 IIS 应用程序上的正常 .NET JIT 延迟。该症状听起来就像您现场有一个 ASP.NET 应用程序并且在一段时间内没有点击它一样。 IIS 工作线程被回收，并且运行时不会对您的应用程序进行 JIT 编译，直到有新的 HTTP 请求到来。这会造成第一个请求可能“永远”等待，但接下来几分钟内到来的每个请求都像“即时”，正如您对代码的期望。
这不是 Azure 特有的，但您可能正在处理与现场运行的 IIS 环境不同的环境（关于默认应用程序池回收设置/回收后的预热设置）。
编辑建议
如果您怀疑这与热身有关，有一些解决方案。
最好的（除非您需要）是管理根本原因，即 IIS 回收应用程序池。默认情况下，这发生在计时器或请求计数上（不确定在 Azure 中是哪一个）。当 web.config 中发生这种情况时，您可以使用
http://www.iis.net/ConfigReference/ system.applicationHost/applicationPools/add/recycling
看看是否有帮助。我建议您在没有受到攻击的时间段（例如半夜）进行定时回收。
另一种选择是确保流量持续访问网站。使用某种轮询软件。像 pingdom 这样的“正常运行时间/状态”监视器非常适合此目的。这是一种黑客方法，但我之前在奇怪的场景中使用过它。 （不推荐）
如果由于特殊的启动要求而不起作用（听起来好像您没有），IIS 有一个预热模块，并且 C# 4.0 有可以提供帮助的预热类。同样，还有更多内容可以确保您控制启动期间而不是启动时发生的情况。
Is this mainly with your web roles? Are they running .NET code? (ASP.NET?, WCF?, etc)
If so, it is possible you are dealing with normal .NET JIT delay on an IIS application that has been recycled due to activity. The symptom sounds just like when you have an ASP.NET app on-site and don't hit it for some amount of time. The IIS worker gets recycled and the runtime will not JIT-compile your app until a new HTTP request comes in. This creates a situation where that first request can take "forever" but every request that comes in in the next few minutes is as "instant" as you'd expect from your code.
This isn't Azure specific, but you could be dealing with an IIS environment different from what you run on-site (in regards to default app pool recycle settings/warmup settings after recycle).
edit with suggestions
If you suspect it's related to warm-up, there are a few solutions.
The best (unless you need otherwise) is to managed the root cause, which is IIS recycling the app pool. By default this happens on a timer or on a request count (not sure which in Azure). You can override when this occurs in your web.config with the
<recycling></recycling>element. IIS.net has the best description of these settings. Take a look at:http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/recycling
and see if that helps. I would recommend just doing a timed recycle during a time period where you aren't being hit (middle of the night, for example)
Another option is to ensure traffic continuously hits the site. with some sort of polling software. "uptime/status" monitors like pingdom are great for this. This is a hack-approach, but I've used it before in odd scenarios. (woudln't recommend)
If that doesn't work due to special startup requirements (which is sounds like you don't have) IIS has a warm-up module, and C# 4.0 has warm-up classes which can help. Again, there are more to ensure you control what happens during startup instead of when startup occurs.