【问题标题】:HTTP Request Timeout Windows Azure DeployHTTP 请求超时 Windows Azure 部署
【发布时间】:2015-08-04 21:13:04
【问题描述】:

我有一个使用 WCF 服务的 MVC 4 网站。当我使用 VS 2012 发布向导部署到 Windows Azure 时,我收到此错误:

上午 10:13:19 - 对“https://management.core.windows.net/42d4257b-5f38-400d-aac5-2e7acee9597d/services/hostedservices/myapp?embed-detail=true”的 HTTP 请求已超过了 00:01:00 的分配超时。分配给此操作的时间可能是较长超时的一部分。

清理项目并发布几次后,错误消失了。我做错了什么?

【问题讨论】:

  • 您是作为 azure 网站发布,还是作为带有 webdeploy 的 azure 托管服务发布?
  • 使用 Azure 项目的 Azure 网站。

标签: azure


【解决方案1】:

当您从 VS 机器开始发布过程时,首先会建立 SSL 隧道,一旦创建隧道,包就会首先从您的机器传输到 Windows Azure 门户。上传完成后,您将看到结果通知被发布回发布结果窗口,就是这样发生的。

在您的情况下,建立 SSL 隧道安全包传输的时间比正常情况要长,这可能是因为您的计算机和 Windows Azure 管理门户之间的网络延迟。出于安全原因,创建隧道较小窗口的时间,如果未创建连接,重试周期将再次启动该过程,即使失败,您也会收到失败消息。这可能是由于任一侧或两侧的流量过多造成的。所以这主要是一个与网络相关的问题,而不是特定于 Windows Azure,因为经过一段时间的连续尝试,您可以上传您的包。

在这种失败/情况下,您可以运行网络捕获实用程序,即netmonwireshark,并查看失败和成功期间所用的时间,以了解各种传输的不同之处。这将帮助您了解潜在的延迟问题。

【讨论】:

  • 我应该将包直接上传到门户中,而不是使用 VS 2012 中的向导吗?如何手动上传包?
  • 当您使用 Windows Azure 网站时,您还有其他选择,例如 Git 和 FTP,因此您可以使用其中任何一种。对于 FTP 部署,您可以从 FTP 应用程序访问您的 Azure 网站并直接复制文件。
  • 我相信这个问题不仅仅是网络延迟。尽管我们的包大小没有改变,但我能够在过去几天在各种网络上重现。我认为这里存在未报告(或根本未报告)的服务中断。
【解决方案2】:

尝试更新您的角色诊断 如下所示

然后更新您的存储凭据,因为它可能已过期。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-02-05
    • 2011-11-05
    • 2010-12-12
    • 2014-04-25
    • 1970-01-01
    相关资源
    最近更新 更多