Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Que faire pour empêcher IIS de recycler mon application ?

ayi

J'ai a WCF service app hosted in IIS. On startup, it goes et fetches a really expensive (in terms of time et cpu) resource to use as local cache.

Malheureusement, IIS seems to recycle le process on a fairly regular basis. So Je suis trying to changez le settings on le Application Pool to assurez-vous que IIS does pas recycle le application. So far, J'ai changez le following:

Limit Interval under CPU depuis 5 to 0.
Idle Time-out under Process Model depuis 20 to 0.
Regular Time Interval under Recycling depuis 1740 to 0.

Will this be enough? And J'ai spécifique questions about le items I changed:

What specifically does Limit Interval setting under CPU mean? Does it mean that si a certain CPU usage is exceeded, le application pool will be recycled?
What exactly does "recycled" mean? Is le application completely torn down et started up again?
What is le difference entre "Worker Process shutdown" et "Application Pool recycling"? The documentation for le Idle Time-out under Process Model talks about shutting down le worker process. While le docs for Regular Time Interval under Recycling talk about application pool recycling. Je ne assez grok le difference entre le two. I thought le w3wp.exe is le worker process qui runs le application pool. Can someone explain le difference to le application entre le two?

The reason for having IIS7 et IIS7.5 tags is parce que le app will run in les deux et hope le answers are le même entre le versions.

Image for reference:

ayi

Recycling

Recycling is usually* où IIS starts up a nouveau process as a container for votre application, et alors gives le old one up to ShutdownTimeLimit to go away of its own volition avant c'est killed.

*- usually: see DisallowOverlappingRotation / "Disable overlapped recycle" setting

C'est destructive, in that le original process et tous its state information are discarded. Using out-of-process session state (eg, State Server ou a database, ou even a cookie si votre state is tiny) can allow you to work around this.

But it is par défaut overlapped - meaning le duration of an outage is minimized parce que le nouveau process starts et is hooked up to le request queue, avant le old one is told "you have [ShutdownTimeLimit] seconds to go away. Please comply."

Settings

To votre question: tous le settings on that page control recycling in certains way. "Shutdown" might be described as "proactive recycling" - où le process itself decides c'est time to go, et exits in an orderly manner.

Reactive recycling is où WAS detects a problem et shoots le process (after establishing a suitable replacement W3WP).

Now, voici certains stuff that can cause recycling of one form ou another:

an ISAPI deciding c'est unhealthy
tout module crashing
idle timeout
cpu limiting
adjusting App Pool properties
as votre mum may have screamed at one point: "Stop picking at it, ou it'll jamais get better!"
"ping" failure * pas actually pinging per se, cos it uses a named pipe - more "life detection"
tous of le settings in le screenshot above

What To Do:

Generally:

Disable Idle timeouts. 20 minutes of inactivity = boom! Old process gone! New process on le suivant incoming request. Set that to zero.

Disable Regular time interval - le 29 hour par défaut has been described as "insane", "annoying" et "clever" by various parties. Actually, seulement two of those are true.

Optionally Turn on DisallowRotationOnConfigChange (above, Disable Reycling for configuration changes) si you juste ne peut pas stop playing avec it - this allows you to change tout app pool setting sans it instantly signaling to le worker processes that it needs to be killed. Vous devez to manually recycle le App Pool to get le settings to take effect, qui lets you pre-set settings et alors use a change window to apply them via votre recycle process.

As a general principle, leave pinging enabled. C'est votre safety net. J'ai seen people turn it off, et alors le site hangs indefinitely sometimes, leading to panic... so si le settings are too aggressive for votre apparently-very-very-slow-to-respond app, back them off a bit et see what you get, plutôt than turning it off. (Unless you've got auto-crash-mode dumping set up for hung W3WPs through votre own monitoring process)

C'est enough to cause a well-behaved process to live forever. If it dies, sure, it'll be replaced. If it hangs, pinging should pick that up et a nouveau one should start within 2 minutes (par défaut; worst-case calc should be: up to ping frequency + ping timeout + startup time limit avant requests start working again).

CPU limiting n'est pas normally interesting, parce que par défaut c'est turned off, et c'est aussi configured to do nothing anyway; si it were configured to kill le process, sure, that'd be a recycling trigger. Leave it off. Note for IIS 8.x, CPU Throttling becomes an option too.

An (IIS) AppPool n'est pas a (.Net) AppDomain (but may contain one/some)

But... alors we get into .Net land, et AppDomain recycling, qui can aussi cause a loss of state. (See: https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)

Short version, you do that by touching a web.config file in votre content folder (again avec le picking!), ou by creating a folder in that folder, ou an ASPX file, or.. autre things... et c'est about as destructive as an App Pool recycle, minus le native-code startup costs (c'est purely a managed code (.Net) concept, so seulement managed code initialization stuff happens here).

Antivirus can aussi trigger this as it scans web.config files, causing a change notification, causing....