Perché IIS imposta automaticamente il riciclaggio del pool di applicazioni ogni 1740 minuti?

Perché IIS predefinito ricicla il pool di app dopo un determinato periodo di tempo? Esiste un motivo specifico diverso da quello che forse la maggior parte delle app Web non gestisce con prudenza la memoria? Dato che stai gestendo correttamente la memoria della tua applicazione, è sicuro andare avanti e disattivarlo? Quali sono alcuni potenziali lati negativi, maggiori vantaggi di disattivare il riciclaggio o mantenerlo attivo?

Sì, il motivo predefinito per impostazione predefinita una volta al giorno è dovuto al fatto che l'app Web potrebbe avere una perdita di memoria. Il più grande svantaggio del riciclo frequente di pool di app IIS è che causerà la lettura di web.config, il caricamento dell'assembly e una ricompilazione delle pagine asp.net e (se non si crede nella pre-compilazione) di codice. Questo è un processo piuttosto pesante e non si verifica fino alla successiva richiesta di una pagina dopo il riciclo del pool di app, rallentando notevolmente quella particolare richiesta. IIS7 ora ha un modulo che puoi scaricare chiamato Riscaldamento dell'applicazione per aiutarti a "risolvere" questo problema.

Personalmente preferisco utilizzare i massimi basati sulla memoria associati alla registrazione all'avvio dell'app piuttosto che alla pianificazione del mio riciclaggio. Questo mi permette di presumere che la mia app non abbia perdite di memoria e di essere smentita quando il pool di app ricicla.

1740 minuti è 29 ore:

All'epoca dello sviluppo di IIS 6, ovvero la versione che introduceva i pool di applicazioni, era necessario impostare un valore predefinito per l'intervallo di tempo regolare quando i pool di applicazioni vengono automaticamente riciclati.

Wade ha suggerito 29 ore per la semplice ragione che è il numero primo più piccolo su 24 . Voleva uno schema sfalsato e non ripetitivo che non si verifica più frequentemente di una volta al giorno. Nelle parole di Wade: "non si ottiene uno schema di risonanza". L'impostazione predefinita è stata 1740 minuti (29 ore) da allora!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

La funzionalità è una sospensione dai classici giorni ASP in cui 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 gli arresti del pool di app ogni 1740 minuti (o se l'app è inattiva per 20 minuti). IIS7 ha continuato la tradizione.

Il consiglio che ho ricevuto da Microsoft a quei tempi era che questo non era necessario a meno che tu non avessi un'app legacy con una perdita di memoria nota. Quindi, se stavi eseguendo un codice puramente gestito, staresti bene.

Spegnilo e monitora i pool di app. La maggior parte delle applicazioni aziendali complesse utilizza un sacco di codice legacy e gran parte di quel codice è un po 'permeabile. Quindi per la maggior parte delle installazioni il riavvio del pool di app occasionalmente non è una cattiva idea.

Esistono altre opzioni come il monitoraggio del tempo di inattività che può essere una soluzione migliore per la tua situazione.

La creazione di un pool di app può richiedere del tempo e rendere l'applicazione meno reattiva, quindi tenerli aggiornati può aiutare le prestazioni.

In effetti, questo è puramente per ripulire le risorse trapelate che potrebbero essere presenti. I 1740 minuti non sono nemmeno l'unico evento scatenante. Succede anche dopo un determinato numero massimo di richieste o dopo aver superato una determinata quantità di memoria del processo di lavoro. È abbastanza ben documentato nella libreria MSDN. Sfortunatamente, questa politica rompe cose come lo stato della sessione e le statiche come i singoli. La tua app dovrà essere sufficientemente robusta per riautenticare gli utenti e / o reinizializzare i singoli in base alle necessità per evitare di disturbare l'esperienza dell'utente. Ci ha costretto a gestire sessioni autenticate nel database piuttosto che nella sessione ASP.NET. Altrimenti, 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.