Azure ASP .net WebApp 请求超时答案

【问题标题】：Azure ASP .net WebApp The request timed outAzure ASP .net WebApp 请求超时
【发布时间】：2016-12-05 00:38:50
【问题描述】：

我已将 ASP .net MVC Web 应用程序部署到 Azure 应用程序服务。

我从我的站点向某个从 DB(DbContext) 获取数据的控制器方法发出 GET 请求。有时从 DB 获取数据的过程可能需要 4 分钟以上。这意味着我的请求在 4 分钟内没有任何操作。之后 Azure 终止连接 - 我收到消息：

500 - 请求超时。
Web 服务器失败在规定时间内回复。

这是一个方法示例：

 [HttpGet]
    public async Task<JsonResult> LongGet(string testString)
    {            
       var task = Task.Delay(360000);
        await task;            
        return Json("Woke", JsonRequestBehavior.AllowGet);
    }

我见过很多这样的问题，但我没有得到答案：

Not working 1 不能提供其他链接 - 声誉太低。

我已阅读此article - 它关于 Azure 负载均衡器，它不适用于 webapps，但它写道，在 Azure webapp 中处理我的问题的常用方法是使用 TCP Keep-alive。所以我改变了我的方法：

[HttpGet]
    public async Task<JsonResult> LongPost(string testString)
    {
        ServicePointManager.SetTcpKeepAlive(true, 1000, 5000);
        ServicePointManager.MaxServicePointIdleTime = 400000;
        ServicePointManager.FindServicePoint(Request.Url).MaxIdleTime = 4000000;
       var task = Task.Delay(360000);
        await task;            
        return Json("Woke", JsonRequestBehavior.AllowGet);
    }

但仍然得到同样的错误。我正在使用简单的 GET 请求，例如

GET /Home/LongPost?testString="abc" HTTP/1.1
Host: longgetrequest.azurewebsites.net
Cache-Control: no-cache
Postman-Token: bde0d996-8cf3-2b3f-20cd-d704016b29c6

所以我正在寻找我做错了什么以及如何在 Azure Web 应用程序中增加请求超时时间的答案。任何帮助表示赞赏。

门户上的 Azure 设置：

Web 套接字 - 开启

始终开启 - 开启

应用设置：

SCM_COMMAND_IDLE_TIMEOUT = 3600

WEBSITE_NODE_DEFAULT_VERSION = 4.2.3

【问题讨论】：

标签： c# asp.net-mvc azure

【解决方案1】：

230 秒。而已。这是 Azure 应用服务中的正在进行的请求超时。它在平台中进行了硬编码，因此无论 TCP 是否保持活动，您仍然受它的约束。

来源 -- 请在此处查看 David Ebbo 的回答：
https://social.msdn.microsoft.com/Forums/en-US/17305ddc-07b2-436c-881b-286d1744c98f/503-errors-with-large-pdf-file?forum=windowsazurewebsitespreview

对于未发回任何数据的请求，有 230 秒（即略少于 4 分钟）超时。之后，客户端得到你看到的 500，即使实际上请求被允许继续服务器端。

如果不了解您的应用程序的更多信息，就很难提出不同的方法。但是很明显，您确实需要一种不同的方法 --

也许返回 202 Accepted 而不是带有 Location 标头以便稍后轮询结果？

【讨论】：

感谢您的帮助。链接下的好信息。它在那里写道：“对于没有发回任何数据的请求，有 230 秒（即略少于 4 分钟）超时。”但是 TCP Keep alive 是为了发回数据而设置的，所以 230 秒后不应将会话标记为空闲。这就是article 中写的内容。如果我在一周内没有其他意见，我会将您的答案标记为正确的。谢谢
虽然 TCP 保持活动适用于 Azure 负载均衡器，但它们不适用于应用服务，因为 230 秒超时是第 7 层事物 (HTTP)，而不是传输层 (TCP、Layer 4).
这仍然是真的，还是他们在去年添加了任何可以配置的东西？
不，还有 230 秒。如果您需要更多，则不再是交互式请求。应立即为202 Accepted 并将工作推迟到后台。
我被告知“保持连接活动较长时间的常见做法是使用 TCP Keep-alive。通过保持持续的网络活动，空闲超时值永远不会命中，并且长时间保持连接”。我在我的客户端应用程序中使用了 SetTcpKeepAlive 方法，我看到这些 TCP 保持活动数据包在 Azure 中来回传送到我的应用服务，但它没有任何影响，并且空闲连接在 230 秒后仍然关闭。这个选项应该有帮助吗？还是真的是关闭连接的 HTTP 级别，而不是 TCP 级别？

【解决方案2】：

我刚刚将我的 Azure 网站从共享环境更改为标准，它可以正常工作。

【讨论】：