在 asp .net core 3 中设置请求超时

Question

I have an asp .net core website with the following in the web.config

<aspNetCore processPath="%LAUNCHER_PATH%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" arguments="%LAUNCHER_ARGS%" requestTimeout="00:20:00">

However it times out with the error

HTTP Error 500.37 - ANCM Failed to Start Within Startup Time Limit

I can see from https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-3.0 there the requestTimeout attribute doesn't apply to in-process hosting. Is there an alternative way to increase the timeout?

Another way forward would be rejig the application so it doesn't take so long to load on first hit, but for now I am trying to avoid that.

Answer 1

I have faced the same issue and after spent a time looking for the root cause and possible solutions, I understood that this happens when there are many app pools on the same machine, which is my case.

Microsoft recommends to stagger the startup process of multiple apps. Another solution would be increase the start up limit .

I've seen some people talking about changing the hostProcess from Inbound to Outbound , this may works, but the IS HTTP Server won't be used, but Kestrel web server is used to process the requests.

I think the best solution is to stagger the startup process either increase the start up limit.

Here you can find more info: https://docs.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-3.0

https://tutorialshelper.com/what-is-the-difference-between-inprocess-and-outofprocess-service-in-asp-net-core/

Answer 2

I have seen the same error occur in IIS hosted .NET Core 3.1 Web API applications.

One suggestion that always works for me is to recycle the IIS App Pool for the application.

If you are hosting applications in a production environment in IIS, I would recommend scheduling recycling of the App Pools regularly as this frees up memory used by the w3wp.exe worker processes.

If the above workaround does not resolve the issue, another suggestion is to debug the application during the startup ConfigureServices() and Configure() methods and see what else could be delaying startup.