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.
To speed your app’s response time, you can…
- Perform the work asynchronously
- Use queues
At this time we do not have any plans to make the timeout configurable or to increase the limit.
Hazael Mojica commented
I know there are changes we can implement to make our app async but that will require development time for multiple screens, while making this configurable would be an easy fix.
This app is a reporting tool that consumes multiple databases for a single report and process huge loads of data, by nature is time consuming and developers didn't plan for a timeout limit, making the requestTimeout configurable will be a great improvement for us.
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.
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
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
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.
Joe Rybacek commented
Using Azure WebApps. It looks like the answer was re-write your application to use web jobs.
Are you using Functions or classic Web Apps?