Request in IIS not being terminated when taking too long - c#

I have a .Net Framework 4.8 api running in a WindowsServer 2022 with IIS.
Sometimes the request does not stop running even when there should a time limit for each request :
I found a similar question but there was no answer :
ASP.Net httpruntime executionTimeout not working (and yes debug=false)
In the web.config, I got the debug property set to false and executionTimeout set to 90 but this didn't solve the issue.
The "Shutdown Time Limit" of the application pool is set to 90 seconds but it also doesnt seem to be working.
I also tried a solution of another similar question, but it didnt work :
.NET Execution Timeout Not Taking Effect in an MVC Web Project
How can i solve this issue?

Related

My Azure WebApp seems to go idle even with AlwaysOn turned on

I have two an Azure WebApps. Both of them have the "AlwaysOn" option set to true, but even now the WebApps go idle after a bit.
If I don't query the WebApp for a few minutes, the next request I make to the WebApp takes significantly longer. Too long to be acceptable for production.
The WebApp runs a C# ASP.NET MVC 5 project which is my project's API.
Can I do anything to prevent this from keeping on happening?
It seems like having turned off the HTTP to HTTPS rewrite solved the issue. The response is still slow, but much faster than before.

Application timeout in ASP.NET Core 1

Is there a way to set the application timeout in ASP.NET Core 1/MVC 6?
What is the default time a site stays in memory without
activity on the site, haven't been able to locate documentation on
this?
I can see when the site spins up from the text log of the stdout but I'm not sure when it goes down or how I can extend (or shrink) that number programatically.
Is there a way to set the application timeout in ASP.NET Core 1/MVC 6?
I don't think so. Application timeouts would be set by the host (IIS example).
What is the default time a site stays in memory without activity on the site, haven't been able to locate documentation on this?
Again, this depends on the host. For IIS, the default time is 20 minutes. When you're debugging with Visual Studio, I'm not sure if it will timeout.

IIS stops responding after recompile

I have my web app I'm developing under local IIS (so not not the visual studio embedded one). It works fine, I can go from page to page...
But if I then change the code and recompile, IIS stops responding properly for ~2 minutes. If I attach the debugger, then there's no executing code, but it just won't serve any pages.
If I stop the App Pool in IIS, then I get a 503 error instantly, but I then am prevented from restarting the App Pool for ~2 minutes with error: Cannot Start Application Pool / There was an error while performing this operation. / Details: / The service cannot accept control messages at this time. (Exception from HRESULT: 0x80070425)
As you can imagine, this is crippling my productivity. Only started happening a couple of days ago, I haven't made any changes to the code which I would have though would cause this problem... and it doesn't matter which page I touch and recompile anyway, it takes just as long to recover. Nothing in the event log.
Any clues as to where to start looking?
Add the following line to your web.config:
<compilation optimizeCompilations="true" />
related article: http://www.dnnsoftware.com/community-blog/cid/135019/a-small-webconfig-setting-that-can-save-you-development-time
I had a similar problem and the installation of the following hotfix fixed the problem for me:
https://support.microsoft.com/en-uk/kb/3090034

Website crashed every two months. App pool recycle fixes the issue

We have a ASP.NET 2.0 (i know it's old!) website hosted on a Windows 2003 server and IIS 6.0. The application periodically crashes after every two months.
We have tried to analyse the memory consumption and other things by using Telerik and very recently Riverbed.
Any idea what should we be looking for?
UPDATE: After searching the WWW I stumbled upon this a fix where they tell that we can increase the request queue limit to stop this issue. Although the root cause analysis is still desirable.

First call of the day to C# webservice very slow - analysis

This question is really around analysis - how do I analyze what's causing the problem?
Situation - we have a C# webservice configured through IIS 7.5, and a website in the same intranet domain hitting the webservice with POST and GET methods. Server is windows 2008 r2 64-bit, C# is 4.0. The first call of the day is slow (30-60 seconds), though I have not checked if I try again later in the day is it slow as well. Subsequent calls are 2-3 seconds. When checked using FireFox web console or firebug, the time is spent on "Waiting" for the webservice.
Things I've tried :-
Setting no recycle time for the webservice AppPool
Setting no idle time-out for the webservice AppPool
Setting proxy bypassonlocal = true and usesystemdefault = false in case it's a proxy look up issue
Nothing's worked so far. My thought is that even if it's C# compile to machine code on first run, it shouldn't 'expire' if the AppPool does not time-out or recycle, yet it is slow everyday.
So flat out of options, how do I go about trying to find the source of the problem? Any diagnostics I can run on the server to check what the webservice is doing?
From your description it sounds as if your webservice might be going to sleep given the first call after a period of inactivity is slow and subsequent calls are faster.
I've seen this behaviour occur on many of my .NET IIS applications, can be frustrating to say the least!
This is however, default .NET behaviour, but there are ways of keeping your application awake, especially as of .NET4.
I refer you to the following article as a first step. Give it a go and see if this makes any difference for you:
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
Good luck!

Categories