Da IIS 4 ad IIS 5, l'architettura di Internet Information Services è basata integralmente sul concetto isolamento del processo : le applicazioni web girano in un'area di memoria condivisa in base al livello di isolamento che è stato impostato nella console di gestione.

Esistono tre diversi profili ai quali associare un sito web (o un'applicazione virtuale):

• Low : è il livello di isolamento più basso. In questo caso l'applicazione girerà nello stesso spazio di memoria di IIS.
• Medium : è il livello intermedio e quello di default. Tutte le applicazioni condividono questo spazio di memoria, ma IIS ne ha uno separato.
• High : è il livello di isolamento più alto, che isola del tutto l'applicazione rispetto alle altre ed allo stesso web server.s

Nel caso in cui un'applicazione ha problemi di stabilità, in genere si utilizza la modalità "High isolation", che fa sì che eventuali crash dell'applicazione non influenzino le altre, che in genere si trovano in una modalità di isolamento intermedia. Questo isolamento, però, può portare controindicazioni, come una maggior consumo di risorse e l'impossibilità, ad esempio, di utilizzare alcune funzionalità come CDONTS/CDOsys.

Nonostante questo isolamento, ogni applicazione potenzialmente scritta male, sia per sbaglio che volontariamente, può portare al blocco totale del web server, per via della particolare architettura di IIS 5, che ha il servizio che controlla lo stato delle applicazioni all'interno dello stesso eseguibile (e quindi nello stesso processo) del web server.

Tenendo a mente questi difetti, il dev team di IIS ha praticamente riscritto da zero il web server, riprogettando dunque l'architettura perché tenga a mente due requisiti indispensabili per le applicazioni moderne: security e availability .

IIS 5 ha una struttura dei pool di esecuzione differente, e comunque non paragonabile come elasticità di configurazione a quella di IIS 6, che permette di impostare n applicazioni all'interno di un pool particolare, e di isolarne delle altre.

Questo, oltre a consentire l'isolamento di applicazioni che per qualche motivo hanno problemi, permette di configurare in maniera dettagliata tutta una serie di funzionalità, tra cui la memoria massima (virtuale e fisica) che l'applicazione può consumare, così come la CPU massima occupata, ed eventuali politiche di riciclaggio del processo , in base ad esempio ad una data ora, ad un numero massimo di richieste soddisfatte.

Si parla di riciclaggio e non riavvio del processo perchè IIS 6 infatti non necessita di riavvii per scaricare la memoria, ma può riciclare i processi in maniera automatica o al verificarsi di problemi particolari.

Il riciclare anziché riavviare permette di evitare il down time dovuto al riavvio stesso, perché in pratica si migliora la disponibilità del server, rendendo inutile il riavvio fisico del processo stesso, tranne in casi davvero rari. Il riciclaggio infatti è molto semplice: il servizio web rimane sempre in attesa, ciò che fa è chiudere un particolare processo e crearne uno nuovo, a cui andranno indirizzate le richieste future. In questo modo non si perde nemmeno una richiesta per strada.

Cos'è un application pool?

Gli application pools sono completamente configurabili dall'utente, dunque non esistono dei profili particolari, ma di fatto possiamo creare quanti profili vogliamo, in base alle esigenze che una certa applicazione, o un insieme di esse, ha manifestato.

Un application pool, come il nome stesso dice, non è altro che un pool, un insieme di applicazioni, che condivideranno alcune impostazioni ma soprattutto gireranno nello stesso spazio di memoria.

A questo punto ci chiederete come si può configurare un web server in modo che gli application pools abbiano una certa logica. Ed infatti mi viene spesso chiesto come agisco nella configurazione degli application pools, visto che è qualcosa che lascia molta fantasia al sistemista.

In genere procedo con la creazione di tre aree principali, ognuna per una tipologia di applicazione:

• una riservata ai siti "normali" , che in genere non hanno un grande traffico e non hanno mai dato nel tempo problemi di performance o scalabilità;
• una riservata ai siti "pericolosi" , con politiche di riciclaggio del processo molto aggressive, che fanno sì che un codice potenzialmente pericoloso, vuoi perché scritto male o semplicemente per il troppo carico non mandi in blocco il servizio che l'applicazione offre;
• una riservata ai siti "protetti" , con politiche di riciclaggio più blande, al fine di garantire la funzionalità del servizio ed evitare continui ricicli del processo.

L'ultima "zona" potrebbe risultare poco utile. In realtà ci sono siti che utilizzano le variabili Session (cosa che in genere evito di fare, visto che ci sono altri sistemi per fare la stessa cosa) e che quindi sono soggetti in maniera più evidente all'unico limite del riciclaggio del processo: viene scaricata la memoria occupata e quindi di fatto si perdono variabili Session ed Application. Se dunque avete un sito di e-commerce, non potete permettervi di far perdere il carrello al cliente solo perché avete deciso di riciclare il processo in maniera così frequente. Meglio creare una zona specifica in cui collocare queste applicazioni, magari proprio una per ogni sito, in modo da tenere separate dalle altre eventuali applicazioni più importanti.

Tra l'altro queste sono tre zone che racchiudono applicazioni molto diffuse, ma nulla ci vieta di creare una zona per ogni singolo sito (anzi, in ambiente di hosting condiviso basato su IIS6 è così che in genere si dovrebbe fare) o addirittura ogni singola applicazioni contenuta in un sito, visto che un sito potrebbe contenere più applicazioni web al suo interno.

Gli application pools ci permettono di evitare che un'applicazione, anche solo un pezzo di codice, possa influenzare il comportamento delle altre e del web server stesso, e quindi il loro utilizzo è consigliato in tutti i casi in cui serva suddividere il carico ma anche la protezione.

Creare un nuovo application pool

Alla base di tutto il discorso fatto finora c'è ovviamente la creazione di un application pool in base alle nostre esigenze, da associare ad esempio ad un solo sito.

Di default ne è presente uno solo, creato in fase di installazione di IIS 6, che lo ricordo ancora una volta non è installato di default, ma deve essere abilitato dal sistemista.

E' sufficiente aprire il tool di gestione di IIS, ad esempio tramite Manage your server , alla voce application server e posizionarsi poi all'interno dell'elenco degli application pools per crearne uno nuovo.

A questo punto è necessario andare nelle proprietà del sito che vogliamo associare a questo specifico application pool e procedere con l'operazione, selezionado il tab "Home Directory" ed impostando l'application pool appena creato quale valore dell'omonima impostazione.

Da ora in poi il nostro sito farà riferimento all'application pool appena creato, per cui è necessario "solamente" impostare le proprietà relative a quest'ultimo perché il sito rientri nelle opzioni appena specificate.

Cerchiamo un attimo di esplorare quindi le proprietà dell'application pool appena creato, per impostarne al meglio le proprietà. Ci basta dunque visualizzare la maschera relativa alle impostazioni dell'application pool.

In base alla funzionalità che vogliamo regolare, avremo altrettante maschere su cui operare:

• Recycling
• Performance
• Health
• Identity

Analizziamole tutte in dettaglio, per dare un significato migliore a ciò che è possibile impostare.