Make Web App Timeout of 230 seconds configurable
Currently there is a 230 second hard timeout in web apps. We have certain reporting functions that run for a large dataset and they timeout. I've seen plenty of workarounds for this, but they all involve a substantial rearchitecting of the app. Since you can put a web app in its own app service plan, this 230 second timeout seems highly arbitrary and against the general flexibility that should be left to the developer and administrator.
Please make this timeout a configurable value and leave it defaulted to 230 seconds.
Bruce Franson
shared this idea
Hello,
To speed your app’s response time, you can…
- Perform the work asynchronously
- Use queues
- Sockets
At this time we do not have any plans to make the timeout configurable or to increase the limit.
Thank you,
Jason
9 comments
-
Vincent Macchia
commented
Another unreasonable response from microsoft. How surprising.
-
Kyle Beckwith
commented
This is bad for those workloads where you want to lift and shift to Azure Cloud. The recommendation from Microsoft is really the right path when building new apps, since one long running request can impact your service directly. Also depending on what you service level you have you have the potential in the shared plans to impact other customers. With that said, if you do go up to Production level plans this should be an option since you are in an isolated environment at a cost to do that. Your business can then decide ROI for rebuilding the product or service or paying for extra service levels.
-
Quirkafleeg
commented
This should not be declined...
For security purposes, failed login attempts should have an exponentially increasing delay, to prevent hackers making DDOS style requests to login screens.
The strongest delay is in the server. However, a bad thought out decline does nothing to add security to any website with a login mechanism. -
Tim van der Horst
commented
This affects the DNN CMS in Azure: DNN upgrades require an open connection and may leave the CMS in an unusable state if interrupted after 230 seconds. The only possible work around is to scale up the web app just for the upgrade.
-
Juan Sixtos
commented
Hello Jeff,
The documentation for this known limitation is here: https://docs.microsoft.com/en-us/azure/app-service/faq-availability-performance-application-issues#why-does-my-request-time-out-after-230-seconds
Best,
Juan
-
Jeff Kissinger
commented
If Microsoft is going to be this inflexible, the solution is not to use Azure. Jason from the Azure App Service team gave no reasoning as to why they came up with this arbitrary timeout which is a typical Microsoft response. They create this timeout so that you have to use a bunch of other Azure stuff (queues, signalr, etc.) that you don't need but that will cost you more. Performing the work asynchronously (as in C# async API signature on the controller) doesn't prevent this timeout from occurring because the API call still has to remain open. This problem just bit me as well. This 230 second timeout isn't documented anywhere that I could find on any official Microsoft materials so here I am googling it and finding it by someone else (not Microsoft). This is a pretty serious limitation, it should be clearly documented so that prospective Azure clients might reconsider the solution that Azure offers.
-
Prabath Perera
commented
I think what you are looking for is WEBSITES_CONTAINER_START_TIME_LIMIT app configuration.
https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web-apps-and-linux/
-
Joe Rybacek
commented
Using Azure WebApps. It looks like the answer was re-write your application to use web jobs.
-
Hi Bruce,
Are you using Functions or classic Web Apps?