Perché IIS esegue automaticamente il riciclo del pool di applicazioni dopo un determinato periodo di tempo? C'è qualche ragione specifica diversa forse dalla maggior parte delle app web non sta gestendo la memoria con prudenza? Dato che stai gestendo correttamente la memoria dell'applicazione, è sicuro andare avanti e disattivarlo? Quali sono i potenziali lati negativi, i vantaggi di disattivare il riciclaggio o di tenerlo acceso?
Sì, il motivo per cui il valore predefinito è una volta al giorno è una preoccupazione che l'app Web potrebbe avere una perdita di memoria. Il più grande svantaggio di riciclare frequentemente i pool di applicazioni IIS è che causerà la lettura di web.config, il caricamento degli assembly e una ricompilazione delle pagine di asp.net e del codice (se non si crede nella pre-compilazione) del codice. Questo è un processo piuttosto pesante e non si verifica fino alla successiva richiesta di una pagina dopo che il pool di app è stato riciclato, rallentando notevolmente quella particolare richiesta. IIS7 ora ha un modulo che puoi scaricare chiamato Application Warm Up per aiutare a" risolvere "questo problema.
Personalmente preferisco utilizzare i massimi basati sulla memoria e accoppiare l'avvio delle app piuttosto che pianificare il riciclo. Ciò mi consente di presumere che la mia app non abbia perdite di memoria e venga smentita quando il pool di app ricicla.
1740 minuti sono 29 ore:
Back when IIS 6 was being developed—which is the version that introduced application pools—a default needed to be set for the Regular Time Interval when application pools are automatically recycled.
Wade suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day. In Wade’s words: “you don’t get a resonate pattern”. The default has been 1740 minutes (29 hours) ever since!
La funzionalità è un passatempo dai classici giorni ASP quando tutto perdeva memoria e dovevi farlo. La maggior parte delle persone ha avuto un riavvio programmato sul server Web durante la notte. IIS6 lo ha automatizzato con spegnimenti del pool di app ogni 1740 minuti (o se l'app è inattiva per 20 minuti). IIS7 ha continuato la tradizione.
I consigli che ho ricevuto da Microsoft in quei giorni era che non era necessario a meno che non avessi un'app legacy con una perdita di memoria nota. Quindi, se tu fossi in esecuzione su un codice gestito in modo esclusivo, sarebbe OK.
Spegni e controlla i pool di app. Le applicazioni aziendali più complesse utilizzano un sacco di codice legacy e gran parte di quel codice è piuttosto scarso. Pertanto, per la maggior parte delle installazioni, il riavvio del pool di applicazioni occasionalmente non è una cattiva idea.
Ci sono altre opzioni come il monitoraggio del tempo di inattività che potrebbe essere una soluzione migliore per la tua situazione.
La rotazione di un pool di app può richiedere un po 'di tempo e rendere l'applicazione meno reattiva, quindi tenerla attiva può aiutare le prestazioni.
In effetti, questo è puramente per ripulire le risorse trapelate che (potrebbero) essere presenti. I 1740 minuti non sono l'unico evento scatenante. Accade anche dopo un numero massimo specifico di richieste o dopo aver superato una quantità specifica di memoria del processo di lavoro. È abbastanza ben documentato nella libreria MSDN. Sfortunatamente, questa politica rompe cose come stato di sessione e statica come i singleton. La tua app dovrà essere abbastanza robusta da consentire di autenticare nuovamente gli utenti e / o inizializzare nuovamente i singleton, se necessario, per evitare di disturbare l'esperienza dell'utente. Ci ha costretto a gestire sessioni autenticate nel database piuttosto che nella sessione ASP.NET. In caso contrario, i nostri utenti sono stati riavviati alla nostra pagina di accesso ogni volta che il server ha riciclato a causa di uno di questi trigger.