Come mantenere in vita gli assembly ASP.NET in AppDomain?

Question

Scenario: Ho un'applicazione ASP.NET enterprise n-Tier distribuita utilizzando progetti di distribuzione Web. Tutti i livelli producono assembly indipendenti che vengono utilizzati dall'applicazione ASP.NET.

Problema: Quando eseguo l'app. per la prima volta dopo la distribuzione, richiede molto tempo per caricare gli assembly dipendenti in memoria. Ma una volta caricata la sua app di illuminazione rapida. Nel caso in cui non ci siano utenti che accedono all'app, IIS scarica gli assembly dalla memoria e quando un utente tenta di accedere all'app su un'istanza successiva, continua a caricare tutti gli assiemi ancora una volta con lo stesso tempo di caricamento necessario ci vuole per la prima volta.

Sto cercando una soluzione che mi permette di mantenere il mio assembly caricati nella memoria persistente sovrascrivendo la natura volatile delle assemblee verso la residenza di memoria.

O qualsiasi altra soluzione che consenta ai miei utenti di utilizzare felicemente l'app risolvendo il problema indicato.

Answer 1

In IIS 6, passare alla sezione Pool di applicazioni e fare clic con il tasto destro del mouse su Proprietà nel pool che ospita l'applicazione ASP.NET in questione. Vai alla scheda Prestazioni e deselezionare "Chiudi processi di lavoro dopo essere stato inattivo per:"

In IIS 7, andare al riquadro Connessioni e trovare Pool di applicazioni, quindi selezionare Impostazioni avanzate per la piscina che ospita l'applicazione. Trova la proprietà "Idle Timeout" e impostala su "0" (questo lo disabilita).

Il valore predefinito è 20 minuti di inattività. Deselezionando la casella, una volta che il tuo AppDomain viene caricato da worker process, non morirà mai (a meno che tu non uccida il processo o qualcosa del genere). Per impostazione predefinita, IIS raggiungerà recycle the process quando raggiunge un certo limite, ad esempio un limite di memoria, ma ne avvierà anche uno nuovo e "eliminerà" tutte le richieste in arrivo finché quello vecchio non sarà utilizzato, in modo da ridurre al minimo le interruzioni.

Ho anche scritto una piccola classe C# che sarà keep your ASP.NET application alive (alternate archived version) in circostanze normali. Poiché viene eseguito all'interno dell'applicazione, ovviamente non può impedire a IIS o a qualsiasi altra cosa di uccidere esplicitamente il processo, ma manterrà l'applicazione "a caldo", ad es. l'app non resterà mai inattiva abbastanza a lungo da consentire a IIS di decidere di spegnerla.

Se non si ha il controllo diretto sulla configurazione di IIS (host condiviso, ad esempio) la soluzione migliore è quella di avere una piccola applicazione in esecuzione su un sistema separato - ad esempio una workstation sempre attiva - che raggiunge il tuo sito ogni x minuti per impedire il timeout del pool di applicazioni. Niente di speciale: un semplice ciclo WebRequest e while() in un'applicazione console.

Answer 2

Ho scritto una piccola applicazione di console C# che mantiene in vita i miei 4 siti ogni 10 minuti tramite l'utilità di pianificazione di Windows. La vita è ancora una volta buona. Non eseguiamo l'app dalle 2:5 del mattino, così i servizi possono eseguire qualsiasi ripulitura della memoria, se è importante. per i nostri siti, comunque, c'è raramente qualcuno in quelle ore.

Answer 3

Uno dei vantaggi di ASP .net è la possibilità di creare istanze di oggetti statiche (condivise).

per evitare la necessità di un processo esterno è possibile creare un timer statico (per esempio) global.asax che richiede una pagina sul dominio con un semplice WebRequest. In questo modo il sito si mantiene in vita fino a quando non viene effettuato un reset manuale della piscina.