Prima di cominciare a parlare di scalabilità è necessario partire definendo questo concetto. Possiamo definire il termine scalabilità come la capacità di un software di aumentare le richieste gestibili in maniera accettabile in termini di performance.
In termini pratici, con la scalabilità un server web quando riceve un grosso numero di richieste riesce a restituire un output senza intaccare più di tanto le performance, senza scalabilità accade il contrario e cioè che il server non è più capace di gestire tutte le richieste, rallenta moltissimo, restituisce errore ed in alcuni casi va in crash. Fin dagli inizi della programmazione di IIS 6.0, Microsoft ha posto molta attenzione alla scalabilità di questo nuovo server web, aumentandone notevolmente le performance.
Da alcuni test è emerso che IIS riusciva ad servire fino a 20,000 siti web statici, 2,000 application pool ed elaborare anche 25,000 richieste di 15kb presenti in cache al secondo. Questi dati sono alcuni esempi divulgati da Microsoft e dipendono moltissimo dall'architettura hardware del server e possono variare a seconda dell'installazione.
Ad ogni modo, rispetto alle precedenti versioni, IIS 6.0 si rivela maggiormente scalabile e più veloce. Sono stati infatti migliorati i thread pool, la gestione delle code e i sistemi di caching, tutti fattori che hanno aumentato notevolmente il throughput.
In un server web comunque, la scalabilità non è solo influenzata dall'architettura software, sono molti i fattori che incidono sull'efficacia della scalabilità. Per esempio la latenza della rete, un quantitativo ridotto di RAM e così via.
Se anche solo un componente non è scalabile, il sistema ne risente nella sua globalità.
In questo articolo vedremo quali sono i fattori che aumentano la scalabilità del server web IIS 6.0.
Nota di assoluta importanza: se si decide di utilizzare i consigli spiegati più avanti, prima di attivarli su un server di produzione è obbligatorio testarli precedentemente su un server di test prima di incappare in qualsiasi tipo di problema.
Le caratteristiche che migliorano la scalabilità di IIS 6.0
Worker Process Isolation Mode
Con IIS 6.0 è stata introdotta la "Worker Process Isolation Mode", ossia un sistema nel quale ogni applicazione è separata dalle altre e quindi gli errori non influenzano applicazioni che stanno girando in un processo differente. Quando si lavora in questo ambito, è possibile fare in modo che le applicazioni girino in diverse application pool, ossia in gruppi configurati diversamente che hanno in comune lo stesso worker process.
Questo significa che è possibile associare ad uno o più URL un gruppo, a cui risponderà un worker process associato a quel gruppo di siti e configurato in maniera specifica per l'esigenza. Per esempio si può definire un gruppo per i siti web statici, uno per quelli dinamici e così via.
Ogni worker process non influenza gli altri perchè operano in maniera indipendente: se un worker process fallisce gli altri worker process continuano a lavorare correttamente. Nel caso in cui un worker process dovesse fallire, HTTP.sys continua a processare la coda delle richieste ed in seguito il WWW Service gira le varie richieste ai worker process liberi.
On-deman process start
Una particolarità di IIS 6.0 è che non alloca risorse all'avvio del web server, ma soltanto quando richiesto. In questo modo non vengono intaccate le risorse di sistema e non viene utilizzata memoria o potenza di calcolo senza una reale necessità. IIS si occupa di allocare le giusto risorse soltanto quando arrivano le richieste.
HTTP Keep-Alives
L'HTTP Keep-Alives è una caratteristica del protocollo HTTP che consente di non dover aprire una nuova connessione ad ogni richiesta ma di mantenere la stessa per sessioni multiple. Per esempio quando il browser effettua una richiesta per la pagina, mantenendo la connessione aperta può riceve nella stessa sessione anche le immagini, i fogli di stile e così via. In questo modo quindi, con una singola connessione al server è possibile gestire richieste multiple.
IIS 6.0 supporta questa caratteristica che consente di aumentare l'efficienza del server, di ridurre la quantità di risorse utilizzate e l'attività del server web.
Web Garden
La Web Garden è una configurazione che consente di avere più worker process pronti a processare le richieste di una singola application pool. Questo significa che quando un worker process è impegnato a servire una pagina di un'application pool, altri worker process rimangono disponibili per servirne ulteriori. L'opzione è configurabile, quindi in base all'application pool si possono instanziare più o meno worker process, aumentando notevolmente la scalabilità del server in situazioni di alto carico.
Processor Affinity
Questa caratteristica di IIS 6.0 consente di associare ad una application pool l'utilizzo di uno specifico processore. Si adatta ovviamente a macchine multi-processore, dove quindi è possibile decidere quale CPU dovrà eseguire i worker process di un application pool. Questa funzionalità è molto interessanto in quanto è possibile, per esempio, decidere che un application pool di 2000 siti statici venga eseguita da una CPU, mentre un application pool di 20 siti dinamici venga eseguita da una seconda CPU. In questo modo si aumentano notevolmente le prestazioni.
Idle Timeout for Worker Processes
È possibile fare in modo che i worker process di una application pool, dopo un quantità di tempo definibile di idle, vengano chiusi. Così facendo, in base alla richiesta, vengono liberate le risorse non utilizzate diminuendo il carico sulla CPU e l'utilizzo della memoria RAM.
Bandwith Throttling
Il bandwith throttling è un'importantissima caratteristica che consente di configurare quanta banda può essere utilizzata dal server web e quanta dai singoli siti ospitati. In server dove sono attivi più servizi quali e-mail, ftp od altro è possibile quindi allocare un certo quantitativo di banda al server web per lasciare il restante al funzionamento degli altri servizi. Inoltre, associando un quantitativo di banda ad ogni sito web o gruppo di siti web, è possibile dedicare più risorse ai gruppi che richiedono più banda e potenza di calcolo, differenziando le varie tipologie di siti ospitati.
HTTP Compression
HTTP prevede di comprimere l'output del server web per poter risparmiare notevolmente in termini di traffico e di banda. Solitamente viene utilizzando un algoritmo gzip per la compressione, anche se bisogna sottolineare che questa caratteristica è funzionante soltanto con i client che la supportano.
64 GB cache capacity
Come introdotto nel precedente articolo sul core di IIS, è stata implementata la funzione di caching delle risposte. In questo modo, il responso si velocizza notevolmente, diminuendo i tempi di latenza ed aumentando le performance. IIS 6.0 consente di allocare fino a 64GB di cache su sistemi x86.
Centralized Binary Logging
In alcuni casi, l'operazione di logging del server web può notevolmente diminuire la velocità del server sovraccaricando CPU e soprattutto i dischi che devono scrivere continuamente dati. IIS 6.0 ha implementato un nuovo sistema centralizzato per la generazione dei log dove ogni sito web spedisce i log non formattati ed in binario in un singolo file di log. È possibile poi ottenere dei log più avanzati dove richiesto ma è una caratteristica da configurare a parte. In questo modo IIS quando è messo duramente sotto stress, risparmia una mole di potenza di calcolo notevole.
Conclusioni
In questo articolo abbiamo visto quali sono le caratteristiche strutturali di IIS 6.0 che aumentano la scalabilità di questo server web. Come si può notare da quanto scritto sopra, l'application pool gioca un ruolo fondamentale in IIS, tanto che le caratteristiche di scalabilità sono studiate principalmente su di essa. Avere conoscenza di queste caratteristiche consente di ottenere un notevole miglioramento nelle performance globali del server web. Il sistema migliore per testare queste caratteristiche è quello di fare tutte le prove su un server che non sia in produzione, in maniera tale che eventuali errori di configurazione non intacchino l'affidabilità del servizio erogato. Soltando dopo un minuzioso tuning ed una grossa quantità di prove è possibile applicare le configurazioni su un server in produzione.