Azure ASP .net WebApp 请求超时 [英] Azure ASP .net WebApp The request timed out

问题描述

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

I have deployed an ASP .net MVC web app to Azure App service.

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

I do a GET request from my site to some controller method which gets data from DB(DbContext). Sometimes the process of getting data from DB may take more than 4 minutes. That means that my request has no action more than 4 minutes. After that Azure kills the connection - I get message:

500 - 请求超时.

Web 服务器失败在规定时间内回复.

500 - The request timed out.

The web server failed to respond within the specified time.

这是一个方法示例:

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

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

I have seen a lot of questions like this, but I got no answer:

不工作 1不能给其他链接 - 声誉太低.

Not working 1 Cant give other link - reputation is too low.

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

I have read this article - its about Azure Load Balancer which is not available for webapps, but its written that common way of handling my problem in Azure webapp is using TCP Keep-alive. So I changed my method:

[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);
    }

但仍然出现相同的错误.我正在使用像

But still get same error. I am using simple GET request like

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 应用程序中的请求超时时间.任何帮助表示赞赏.

So I am looking for the answer what am I doing wrong and how to increase request timeout time in Azure Web app. Any help is appreciated.

门户上的天蓝色设置:

Web 套接字 - 开启

Web sockets - On

始终开启 - 开启

应用设置:

SCM_COMMAND_IDLE_TIMEOUT = 3600

SCM_COMMAND_IDLE_TIMEOUT = 3600

WEBSITE_NODE_DEFAULT_VERSION = 4.2.3

WEBSITE_NODE_DEFAULT_VERSION = 4.2.3

推荐答案

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

230 seconds. That's it. That's the in-flight request timeout in Azure App Service. It's hardcoded in the platform so TCP keep-alives or not you're still bound by it.

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

Source -- see David Ebbo's answer here:
https://social.msdn.microsoft.com/Forums/en-US/17305ddc-07b2-436c-881b-286d1744c98f/503-errors-with-large-pdf-file?forum=windowsazurewebsitespreview

对于没有发回任何数据的请求，有 230 秒(即不到 4 分钟)超时.之后，客户端得到你看到的 500，即使实际上请求被允许继续服务器端.

There is a 230 second (i.e. a little less than 4 mins) timeout for requests that are not sending any data back. After that, the client gets the 500 you saw, even though in reality the request is allowed to continue server side.

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

Without knowing more about your application it's difficult to suggest a different approach. However what's clear is that you do need a different approach --

也许返回一个 202 Accepted 而不是一个 Location 标头以便稍后轮询结果?

Maybe return a 202 Accepted instead with a Location header to poll for the result later?

这篇关于Azure ASP .net WebApp 请求超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！