IIS 7.0

I 10 miglioramenti principali delle prestazioni in IIS 7.0

Mike Volodarsky

 

Panoramica:

• Riduzione al minimo del footprint dell'applicazione
• Riduzione dei costi di larghezza di banda
• Utilizzo di funzionalità avanzate di memorizzazione nella cache

Indice

Server Web più snelli
Costruzione su un sistema operativo snello
Topologie specializzate delle applicazioni
Supporto migliorato delle applicazioni
Aumento della densità delle applicazioni
Riduzione della larghezza di banda con la compressione
Limitazione della velocità in bit per contenuti multimediali
Cache di output
Conversione di codice ISAPI in moduli IIS 7.0
Estendibilità del server
Conclusioni

Quando incontro delle aziende che stanno pensando di adottare IIS 7.0, una domanda che inevitabilmente si pone è se il passaggio a IIS 7.0 migliorerà le prestazioni dei server e delle applicazioni. La

risposta è generalmente sì, tuttavia non c'è da stupirsi se all'inizio non si riscontrano miglioramenti delle prestazioni quando si esegue la migrazione delle applicazioni a IIS 7.0.

Per capire questo fenomeno, è necessario comprendere la natura dell'ultima versione. IIS 6.0 era una versione di progettazione con tre obiettivi principali: miglioramento della sicurezza, maggiore affidabilità e prestazioni ottimizzate. IIS 7.0 è invece una versione per piattaforma, il cui scopo consiste nel convertire gli eccellenti componenti di base del server Web (server core) della versione precedente in una piattaforma modulare ed espandibile che supporti i principali scenari attuali di distribuzione e gestione.

Molte delle modifiche architettoniche e delle nuove funzionalità potrebbero avere in realtà un impatto negativo sulle prestazioni del server Web — considerando, ad esempio, che una delle modifiche principali consiste nella "scomposizione" di percorsi di codice server Web altamente ottimizzati in moduli autonomi che non ricevono nessun trattamento speciale dal server Web. Tuttavia, grazie al duro lavoro sulle prestazioni eseguito dal team di IIS, IIS 7.0 mantiene le prestazioni allo stesso livello della versione precedente e in alcuni casi le supera. Come posso testimoniare personalmente avendo lavorato sui componenti di base del server Web e sulla pipeline integrata, questo risultato ha richiesto molta creatività nella progettazione e un grosso impegno nell'implementazione del prodotto.

Ciò nonostante, IIS 7.0 ha potenzialità molto più alte di produrre miglioramenti significativi delle prestazioni e di ridurre i costi associati alle prestazioni della server farm rispetto a qualsiasi altra versione precedente di IIS.

Non è detto che questi vantaggi siano visibili semplicemente eseguendo la migrazione a IIS 7.0, tuttavia in alcuni ambienti questo potrebbe verificarsi. Ad esempio, Microsoft.com ha rilevato un miglioramento del 10% nell'efficienza della CPU (è possibile consultare l'analisi completa sul blog del team di Microsoft.com alla pagina go.microsoft.com/fwlink/?LinkId=122497). È anche possibile rilevare dei miglioramenti notevoli in aree specifiche, compresi Secure Sockets Layer (SSL) e l'autenticazione Windows® (entrambi eseguiti nel kernel) e una migliore scalabilità verticale nei computer multiprocessore e multicore.

Tuttavia, la vera forza di IIS 7.0 non deriva dai miglioramenti incrementali delle prestazioni apportati alle funzionalità esistenti. I miglioramenti derivano invece dalle nuove funzionalità, che occorre utilizzare attivamente. Queste si basano sulla flessibilità, sulla natura espandibile della piattaforma e sulle nuove caratteristiche di prestazioni. In questo articolo desidero illustrare i 10 più importanti miglioramenti delle prestazioni che è possibile ottenere passando a IIS 7.0.

Server Web più snelli

La capacità di distribuire server IIS 7.0 snelli deriva dall'architettura modulare del server. In pratica, tutte le funzionalità del server Web vengono implementate come componenti modulari che possono essere aggiunti o rimossi singolarmente. In questo modo, è possibile rimuovere le funzionalità del server che non sono necessarie per il funzionamento di un'applicazione apportando vantaggi notevoli, ad esempio una superficie di attacco considerevolmente ridotta, un footprint operativo inferiore e prestazioni migliorate.

La funzionalità server Web completa di IIS 7.0 comprende 44 moduli, tra cui moduli IIS nativi e moduli ASP.NET che forniscono servizi per la pipeline integrata. Questi moduli offrono servizi come l'autenticazione (moduli Autenticazione Windows e Autenticazione digest), il supporto per il framework applicazione (modulo FastCGI), i servizi applicazione (modulo Stato sessione), la protezione (modulo Filtro richieste) e le prestazioni (modulo Cache di output). A prescindere dal numero di moduli disponibili, un server Web minimo che gestisce solamente contenuto statico può essere operativo con appena 2 moduli!

I moduli non necessari potrebbero causare un overhead notevole, ad esempio quando si eseguono operazioni di registrazione delle richieste e analisi delle richieste non riuscite. La rimozione di tali moduli negli ambienti in cui non sono richiesti può comportare un aumento della velocità effettiva e risposte più rapide che abbassano i criteri di misurazione tempo di ricezione primo byte (TTFB, time to first byte) e tempo di ricezione ultimo byte (TTLB, time to last byte) per il carico di lavoro del server.

La Figura 1 illustra i risultati di un semplice test sulla velocità effettiva di un file HTML (carico di lavoro statico) e di una pagina ASP.NET Hello World (carico di lavoro ASP.NET) quando si utilizza una configurazione contenente il set completo di funzionalità, il set predefinito di funzionalità per quel particolare carico di lavoro e il set di funzionalità minimo necessario per il carico di lavoro. Anche se la maggior parte delle funzionalità non essenziali è già disattivata nella configurazione completa, la loro rimozione completa nella configurazione minima comporta un aumento notevole della velocità effettiva sia per il carico di lavoro statico che per il carico di lavoro ASP.NET.

Figura 1 Valori della velocità effettiva del carico di lavoro statico e del carico di lavoro ASP.NET nelle tre diverse configurazioni con 100 client simultanei (fare clic sull'immagine per ingrandirla)

Inoltre, è possibile riscontare miglioramenti nel footprint di memoria e una più elevata densità del sito, soprattutto in ambienti di hosting condiviso o nei casi in cui si utilizzano molti processi di lavoro. Questo si ottiene di solito caricando meno DLL in ogni processo ed eliminando eventuali allocazioni di memoria che si verificano durante l'inizializzazione del modulo e l'elaborazione delle richieste. La Figura 2 illustra l'utilizzo della memoria (byte privati del processo di lavoro IIS) nello stesso test della velocità effettiva. In questo esempio i miglioramenti non sono particolarmente evidenti, tuttavia gli aumenti sono in linea con le aspettative, in quanto l'overhead dell'appdomain ASP.NET è relativamente più alto dei risparmi iniziali forniti dai moduli rimossi.

Figura 2 Utilizzo della memoria (byte privati) del carico di lavoro statico e nel carico di lavoro ASP.NET in tre diverse configurazioni con 100 client simultanei (fare clic sull'immagine per ingrandirla)

IIS 7.0 fornisce inoltre maggiore controllo sull'abilitazione dei moduli a livello di applicazione, oltre al controllo sull'utilizzo dei moduli basato sul carico di lavoro tramite le precondizioni del modulo. Sebbene questo richieda una configurazione avanzata, può fornire vantaggi aggiuntivi in ambienti multisito o per applicazioni che supportano più carichi di lavoro distinti.

Attenzione però: determinare le funzionalità richieste non è sempre facile. Occorre considerare non solo la funzionalità minima necessaria a supportare il framework applicazione, ma anche eventuali funzioni aggiuntive di cui l'applicazione potrebbe avere indirettamente bisogno. Ad esempio, l'applicazione potrebbe dipendere da forme di autenticazione specifiche o utilizzare la semantica di autorizzazione fornita dalle varie funzionalità IIS che, se rimosse, potrebbero compromettere la protezione dell'applicazione. Analogamente, per funzionare correttamente o per raggiungere prestazioni ottimali l'applicazione potrebbe aver bisogno di alcuni moduli che, se rimossi, potrebbero causare comportamenti errati o un peggioramento delle prestazioni.

Costruzione su un sistema operativo snello

Windows Server® 2008 rende anche disponibile la componentizzazione a livello di sistema operativo, che è possibile utilizzare per ridurre ulteriormente la superficie del server Web. Server Core è un'opzione di installazione minima per il sistema operativo Windows Server 2008 e contiene un set minimo di sottosistemi di base del sistema operativo. Server Core è l'ambiente ideale per i server Web IIS 7.0 snelli.

Tuttavia, quando si valuta Server Core, si tenga presente che alcune limitazioni potrebbero avere conseguenze sull'applicazione. Server Core non fornisce supporto per Microsoft® .NET Framework, il che significa che ASP.NET, l'estendibilità .NET per IIS e Gestione IIS non sono disponibili. Inoltre, le attività di gestione locali richiedono strumenti della riga di comando perché non è presente Microsoft Management Console (MMC). Dal punto di vista delle prestazioni, se si sta già utilizzando correttamente la componentizzazione di IIS, potrebbero non essere visibili miglioramenti nel footprint della memoria o nella velocità effettiva del carico di lavoro dell'applicazione in esecuzione su Server Core rispetto a un'implementazione Windows Server completa. Questo perché il lavoro eseguito da IIS e dall'applicazione è lo stesso su entrambe le piattaforme. Tuttavia, c'è un elemento in cui la differenza è visibile: il footprint globale del server, sia per quanto riguarda lo spazio su disco sia per quanto riguarda l'utilizzo della memoria.

Ad esempio, la Figura 3 illustra la differenza di footprint dopo aver eseguito il test del carico di lavoro statico su una configurazione Windows Server 2008 completa e su una configurazione Server Core. Mentre il footprint di IIS è praticamente identico in entrambi i casi, il footprint più basso del sistema operativo in Server Core richiede decisamente meno memoria per supportare il carico di lavoro. Il footprint più basso potrebbe inoltre consentire di distribuire il carico di lavoro dell'applicazione su hardware meno potente, spostando l'attenzione dall'ambiente di funzionamento alle richieste di elaborazione dell'applicazione. Ovviamente, questo rende Server Core un'ottima opzione per gli ambienti virtualizzati.

Figura 3 Footprint di memoria della versione completa di Windows Server 2008 rispetto a Server Core dopo l'esecuzione del test del carico di lavoro statico (fare clic sull'immagine per ingrandirla)

Topologie specializzate delle applicazioni

Quando si cerca di ottimizzare i carichi di lavoro delle applicazioni, è possibile dividere il carico di lavoro in parti distinte. Ad esempio, anziché eseguire l'applicazione su una farm di 30 server Web identici, è possibile eseguirla su 10 server Web, 5 server applicazioni e 3 server proxy che eseguono la memorizzazione nella cache e la compressione.

Questa specializzazione comporta dei vantaggi per diversi motivi. In primo luogo, le prestazioni di molti carichi di lavoro delle applicazioni dipendono soprattutto da una serie di risorse condivise, come la memoria, che potrebbero essere reclamate da varie parti dell'applicazione. La competizione per queste risorse può creare dei colli di bottiglia che impediscono a ciascun server di essere pienamente utilizzato da altre risorse. La separazione delle parti dell'applicazione consente alle parti di accedere immediatamente alle risorse senza creare competizione, migliorando l'efficienza dello stesso set di risorse hardware.

In secondo luogo, la specializzazione potrebbe consentire all'applicazione di migliorare la memorizzazione locale nella cache, con un conseguente miglioramento delle prestazioni. Questo comprende le cache di livello inferiore, come il TLB (Translation Lookaside Buffer) della memoria virtuale, la cache del file system e le altre cache del sistema operativo e dell'applicazione. Anche la CPU contribuisce a migliorare lo sfruttamento locale delle risorse. Riducendo il numero di attività parallele in esecuzione e concentrandosi soltanto su una parte specifica, l'applicazione può ridurre il numero di commutazioni di contesto e incrementare al massimo il lavoro eseguito dalla CPU.

Inoltre, la specializzazione consente l'ottimizzazione in base ai carichi di lavoro, in modo che ciascuna parte dell'applicazione possa lavorare in modo più efficace. Molte di queste ottimizzazioni non sono possibili quando l'intera applicazione è supportata sullo stesso server, a causa di confitti di esigenze tra le diverse parti dell'applicazione.

Uno scenario comune in cui questo si verifica è la configurazione del threading di IIS e ASP.NET, che ha influisce notevolmente sull'esecuzione simultanea e indirettamente sull'utilizzo della memoria, la latenza e la velocità effettiva di molte applicazioni. Il carico di lavoro statico dei file in IIS è estremamente asincrono e richiede un limite elevato di richieste simultanee, ma trae vantaggio da un numero molto basso di thread disponibili. D'altra parte, molte delle funzionalità di ASP.NET sono sincrone, comportano blocchi di lunga durata e richiedono un numero elevato di thread, mentre altre richiedono un limite di esecuzione simultanea più basso per ridurre l'impatto sulla memoria. Separando il carico di lavoro statico e dividendo le parti della pipeline di elaborazione delle richieste in un processo o server separato, è possibile ottimizzare l'esecuzione simultanea di ciascun carico di lavoro.

Infine, la specializzazione può comportare una maggiore scalabilità globale, in quanto consente all'applicazione di utilizzare la scalabilità orizzontale per carichi di lavoro discreti o per parti dell'applicazione indipendenti l'una dall'altra. In questo modo è possibile abilitare la topologia dell'applicazione per migliorarne la capacità e la ridondanza dove è più necessario, piuttosto che richiedere di applicare lo stesso modello all'intera applicazione. In questo modello, le risorse specializzate potrebbero essere server fisici, server virtuali o anche pool di applicazioni sullo stesso computer.

Quando si valutano i possibili vantaggi della specializzazione per la topologia dell'applicazione, è necessario innanzitutto individuare i colli di bottiglia dovuti all'elaborazione o a un utilizzo intensivo delle risorse nell'applicazione. Queste aree dovrebbero essere i primi candidati per la specializzazione, in quanto potrebbero fornire potenziale significativo per l'ottimizzazione se isolate, e in quanto richiederanno la più elevata scalabilità orizzontale. Inoltre, occorre valutare se l'isolamento consente al resto dell'applicazione di utilizzare le risorse in modo più efficace. Infine, occorre valutare l'overhead del meccanismo di connettività necessario per rimettere insieme i componenti isolati dell'applicazione.

Supporto migliorato delle applicazioni

IIS 7.0 è dotato di supporto esteso per i framework applicazione tramite FastCGI, un protocollo aperto supportato da molti framework applicazione open source che altrimenti non potrebbero supportare un'integrazione nativa con IIS stabile e ad elevate prestazioni. A differenza del protocollo CGI (Common Gateway Interface), che è stato supportato da IIS per lungo tempo, FastCGI fornisce prestazioni notevolmente migliorate sulla piattaforma Windows. Questo è dovuto principalmente all'architettura di processo riutilizzabile di FastCGI, che elimina la necessità di creare un processo per ciascuna richiesta, consentendo ai client di sfruttare le connessioni keep-alive permanenti.

Se il supporto dei framework applicazione di IIS è assicurato da CGI o da un altro meccanismo, è possibile migliorare le prestazioni (e in alcuni casi la stabilità) passando al protocollo FastCGI.

Il primo framework applicazione che sfrutta questo supporto è PHP. Il team di IIS ha lavorato direttamente con Zend Technologies per garantire che l'implementazione di Fast­CGI in IIS funzioni bene con PHP e consenta miglioramenti delle prestazioni nel framework PHP su Windows. Per ulteriori informazioni sul progetto, consultare il mio blog alla pagina go.microsoft.com/fwlink/?LinkId=122509. Se si ha a disposizione un misto di tecnologie server Web costituite da applicazioni ASP o ASP.NET in esecuzione su IIS, oltre a PHP o altri framework applicazione compatibili con FastCGI tramite altre tecnologie, è possibile consolidare queste applicazioni sulla piattaforma IIS 7.0.

Spostando PHP e altri framework applicazione in IIS 7.0 e FastCGI, è possibile usufruire di varie funzionalità di IIS 7.0, tra cui la pipeline integrata ASP.NET. Questa opzione è particolarmente utile per migliorare i framework applicazione con servizi ASP.NET senza convertirli in ASP.NET. Consente inoltre alle applicazioni di utilizzare framework diversi per collaborare. Per un esempio di come utilizzare questa opzione per migliorare la funzionalità e le prestazioni delle applicazioni esistenti senza modificare il codice, consultare il mio articolo su MSDN® Magazine "Potenzia le tue applicazioni con la pipeline ASP.NET integrata" (disponibile all'indirizzo msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7).

Aumento della densità delle applicazioni

IIS 7.0 comprende molti miglioramenti intesi ad accrescere la densità delle applicazioni ospitate su un unico server. Questi miglioramenti fanno parte delle numerose funzionalità rese disponibili da IIS 7.0 per ottimizzare la qualità dell'hosting condiviso, fra cui il provisioning migliorato dei siti e un maggiore isolamento delle applicazioni.

Dal punto di vista delle prestazioni, i miglioramenti si concentrano principalmente su due aspetti della densità delle applicazioni: l'aumento del numero di applicazioni di cui può essere effettuato il provisioning su un server IIS 7.0 e l'aumento del numero di applicazioni che possono essere attive in qualsiasi momento.

Si tenga presente che con IIS 7.0 è possibile effettuare il provisioning su ogni server di un numero di applicazioni più elevato di quanto consentito in passato — in alcuni test interni si è arrivati fino a 100.000 siti su un solo server. Questo è possibile grazie alla capacità di creare e configurare un gran numero di siti e applicazioni.

Attenzione però: per ottenere un provisioning ad alta velocità, è necessario passare alle API della nuova configurazione, in quanto le API della configurazione precedente sono inadeguate. Inoltre, non tutte le API della configurazione IIS forniscono le stesse caratteristiche di prestazioni, quindi è necessario effettuare una scelta attenta per ottimizzare le prestazioni. Se non si è sicuri, optare per opzioni di configurazione che sfruttano direttamente i nuovi oggetti di configurazione IIS, tra cui il namespace Microsoft.Web.Administration, lo strumento della riga di comando AppCmd.exe e gli oggetti di configurazione IIS COM accessibili da script o da codice .NET o C++.

La differenza tra il numero di siti di cui è possibile effettuare il provisioning e il numero di siti che possono essere attivi è una distinzione molto importante nell'architettura IIS, che utilizza processi di lavoro e applicazioni permanenti per l'elaborazione delle richieste. In questo modello, le applicazioni attive utilizzano più risorse sul server, ma garantiscono anche prestazioni costantemente migliori grazie alla memorizzazione nella cache e all'eliminazione dei costi di inizializzazione.

Dato che ogni applicazione attiva richiede una certa quantità di memoria e un processo di lavoro separato (se si utilizza il modello di isolamento dell'applicazione consigliato), il numero di applicazioni attive dipende in gran parte dal footprint di memoria dell'applicazione. Quindi, mentre una singola applicazione utilizzata soltanto per il contenuto statico potrebbe richiedere solo 3 MB per il suo processo di lavoro (e può anche condividere lo stesso processo di lavoro con altre applicazioni di contenuto statico), alcune applicazioni dinamiche potrebbero richiedere 100 MB o più di RAM anche in condizioni di basso utilizzo. In questo caso, l'overhead di memoria del processo di lavoro IIS è praticamente irrilevante se paragonato al footprint dell'applicazione quando si definisce la densità massima possibile.

Nello scenario tipico dell'hosting condiviso, è piuttosto comune la cosiddetta "distribuzione 80/20", in cui l'80% delle richieste viene inviato al 20% dei siti. Questo fa sì che solo una piccola percentuale di siti sia attiva in un dato momento. Per consentire un numero più elevato di siti attivi, IIS 7.0 rende disponibile la gestione attiva della durata. Questa aiuta a recuperare memoria dalle applicazioni non attive per consentire l'hosting di più applicazioni attive.

IIS 7.0 introduce un nuovo algoritmo chiamato inattività dinamica, che regola i tempi di inattività dei processi di lavoro in base alla memoria disponibile sul server. Man mano che la memoria disponibile diminuisce, le applicazioni inattive vengono rimosse più rapidamente, consentendo l'hosting di più applicazioni attive. Tuttavia, se la memoria è disponibile, i timeout possono rimanere ampi, per consentire prestazioni migliori e mantenere lo stato delle applicazioni. Oltre a consentire a più applicazioni di essere attive, l'inattività dinamica aiuta anche a evitare condizioni di memoria scarsa, che causano un notevole peggioramento delle prestazioni a causa del sovraccarico.

Per consentire l'hosting di molte applicazioni attive, è necessario utilizzare un sistema operativo a 64 bit, perché in questo modo il sistema operativo può sfruttare più di 4 GB di memoria. Inoltre, è possibile configurare i processi di lavoro IIS perché vengano eseguiti in modalità 32 bit (SysWoW64), in modo che utilizzino meno memoria e consentano al sistema operativo di sfruttare più memoria rispetto a un ambiente a 32 bit.

Riduzione della larghezza di banda con la compressione

Non stupisce che i costi di larghezza di banda siano uno dei costi più elevati per un datacenter che utilizza Internet. Inoltre, la larghezza di banda necessaria per trasmettere il contenuto richiesto è un fattore chiave per la capacità di risposta percepita dell'applicazione.

Uno dei modi più efficaci per ridurre la larghezza di banda necessaria ad assicurare la capacità di risposta dell'applicazione è utilizzare la compressione HTTP. Questa può ridurre notevolmente le dimensioni della risposta, spesso di circa il 10% se applicata a contenuto di testo facilmente comprimibile come l'HTML. L'aspetto migliore è che praticamente tutti i browser desktop la supportano, e i costi di decompressione sull'hardware del desktop sono minori rispetto ai risparmi di latenza ottenuti dall'invio di un numero minore di dati. E poiché la compressione è basata sulla negoziazione Content-Encoding definita nel protocollo HTTP 1.1, la sua attivazione è sicura per i client che non supportano la compressione — questi client ricevono semplicemente una versione non compressa del contenuto.

IIS 7.0 rende disponibili due funzionalità di compressione introdotte nella versione precedente: la compressione statica e la compressione dinamica. La compressione statica effettua una compressione preliminare del contenuto statico e lo salva su disco, consentendo alle richieste future di utilizzare direttamente il contenuto compresso senza dover effettuare la compressione. La compressione dinamica comprime le risposte in tempo reale, pertanto consente la compressione per le risposte generate dalle applicazioni. Tutti i framework applicazione di IIS 7.0 possono sfruttare la compressione dinamica, compresi ASP, ASP.NET o PHP.

Contrariamente a quanto si crede, la compressione dinamica solitamente non comporta un overhead insostenibile per la CPU. Infatti, alla compressione dinamica è spesso attribuibile meno del 5% dell'utilizzo totale della CPU su un server occupato. La compressione dinamica può essere distribuita in modo piuttosto libero per risparmiare al massimo sulla larghezza di banda per i carichi di lavoro dell'applicazione.

È possibile ottimizzare ulteriormente l'overhead della compressione configurando la forza di compressione per raggiungere la compressione desiderata rispetto al valore dell'overhead della CPU. E non solo: è anche possibile configurare l'applicazione per attivare la memorizzazione nella cache del contenuto compresso, che elimina l'overhead della compressione nei riscontri della cache in quanto viene utilizzato contenuto già compresso. Si tenga presente che sia la cache dell'output di ASP.NET che la cache dell'output di IIS sono state dotate della funzionalità opzionale che memorizza nella cache il contenuto compresso per i client che lo supportano, oltre a gestire le richieste provenienti dai client che richiedono contenuto non compresso.

Limitazione della velocità in bit per contenuti multimediali

Poiché sempre più siti offrono contenuti multimediali, i costi di larghezza di banda per molte aziende sono saliti alle stelle. Quel che è peggio, un'ampia percentuale di larghezza di banda viene sprecata, in quanto il contenuto multimediale inviato al client non viene mai realmente utilizzato. Perché questo si verifica?

Immagina l'ultima volta in cui hai guardato un video online o hai visto un annuncio video mentre navigavi su Internet. Hai guardato il video fino alla fine? Molto spesso gli utenti navigano nei siti di video per guardare soltanto una parte di un video, prima di passare al video successivo o chiudere la pagina. Tuttavia, un server Web che utilizza il download progressivo per rendere disponibile il video invia solitamente molti più dati del necessario per quei pochi secondi di riproduzione. La maggior parte dei dati non viene mai utilizzata.

Se i video vengono mediamente riprodotti per 5 secondi ma il sistema esegue il buffering di 30 secondi di dati video in quei 5 secondi, viene potenzialmente sprecato oltre l'80% della larghezza di banda.

Un anno fa, per risolvere questo problema per un cliente in possesso di una versione beta di IIS 7.0, ho scritto un modulo di limitazione della larghezza di banda che rilevava automaticamente la velocità in bit del video per assicurare che il server trasmettesse il video al client più o meno alla stessa velocità. Il team multimediale di IIS ha adottato questo modulo, denominato "Bit Rate Throttling Module" (vedere la Figura 4), e lo ha reso disponibile nell'area download di iis.net (iis.net/downloads/­?tabid=34&g=6&i=1640). Per ulteriori informazioni su questo modulo, consultare il blog di Scott Guthrie (disponibile alla pagina go.microsoft.com/fwlink/?LinkId=122514).

Figura 4 La limitazione della velocità in bit riduce l'utilizzo della larghezza di banda (fare clic sull'immagine per ingrandirla)

Il modulo per la limitazione della velocità in bit rileva automaticamente la velocità di codifica dei tipi di video più comuni. È possibile controllare quanti dati si desidera pre-inviare al client per eliminare i ritardi di buffering iniziali (avvio veloce) e stabilire a quale percentuale di velocità codificata si desidera trasmettere il contenuto. È anche possibile configurare molte altre opzioni, come la larghezza di banda massima e le connessioni simultanee, e controllare il modulo a livello di programmazione.

Cache di output

In generale, la memorizzazione nella cache è il metodo migliore per migliorare le prestazioni delle applicazioni che eseguono operazioni ripetitive. A differenza dei miglioramenti delle prestazioni specifici di un'applicazione, che richiedono spesso molti sforzi e vengono sminuiti dall'overhead di elaborazione dell'applicazione, la memorizzazione nella cache elimina la necessità di richieste ripetute per lo stesso contenuto.

Prima di IIS 7.0, sia IIS che ASP.NET offrivano funzionalità di memorizzazione nella cache tramite la cache del kernel IIS e la cache di output di ASP.NET. La cache del kernel IIS garantiva le prestazioni migliori, ma serviva principalmente per il contenuto statico. La cache di output di ASP.NET era una soluzione decisamente più completa per memorizzare nella cache il contenuto dinamico, ma le prestazioni erano più lente e la gestione della memoria meno efficiente. La nuova cache di output di IIS 7.0 elimina il divario tra la cache del kernel IIS e la cache di output di ASP.NET.

La cache di output di IIS 7.0 consente la memorizzazione nella cache del contenuto dinamico da qualsiasi applicazione, tra cui ASP, ASP.NET, PHP e qualsiasi altro framework applicazione compatibile con IIS 7.0. Fornendo supporto di base per la variabilità e la scadenza del contenuto, questa nuova funzionalità consente di memorizzare nella cache il contenuto che non può essere memorizzato dalla cache del kernel IIS. Attiva anche l'uso della cache del kernel per il contenuto conforme alle restrizioni.

Inoltre, la cache di output di IIS 7.0 rappresenta anche un'alternativa dalle prestazioni migliori rispetto alla cache di output di ASP.NET per il contenuto ASP.NET che non richiede funzionalità cache avanzate (come l'invalidamento e le dipendenze della cache) che sono disponibili solo nella cache di output di ASP.NET.

Per quanto riguarda la cache di output, le difficoltà maggiori risiedono solitamente nel definire la scadenza corretta del contenuto, l'invalidamento e i criteri di variabilità che consentono un'efficace memorizzazione nella cache delle risposte pur mantenendo la correttezza e l'aggiornamento della cache necessari. Nella maggior parte dei casi, è sufficiente configurare regole corrette di memorizzazione nella cache, ma alcune situazioni richiedono criteri più complessi che dipendono dalle informazioni di runtime. Per risolvere questo problema, la cache di output di IIS 7.0 fornisce API programmatiche che possono essere utilizzate per garantire il corretto comportamento della cache. In questo modo si liberano le potenzialità delle prestazioni di memorizzazione nella cache per i contenuti che altrimenti non potrebbero usufruirne. Inoltre, la pipeline integrata ASP.NET consente l'utilizzo della cache di output di ASP.NET per contenuti non ASP.NET.

L'utilizzo della cache di output per il contenuto dinamico può presentare delle difficoltà e potrebbe richiedere una strategia multilivello per sfruttare al massimo l'efficienza e la flessibilità delle varie funzioni di memorizzazione nella cache sulla piattaforma IIS 7.0. Questo comprende spesso la descrizione di più parametri che influiscono sulla risposta e la definizione di strategie sia di scadenza che di invalidamento per mantenere aggiornata la cache, e infine la determinazione di quale cache debba supportare la semantica richiesta.

Ma il gioco vale quasi sempre la candela. L'implementazione della cache di output di IIS 7.0, consente di ottenere miglioramenti di svariati ordini di grandezza nella velocità effettiva dell'applicazione e una corrispondente riduzione del carico del database e dei componenti a livello aziendale.

Conversione del codice ISAPI in moduli IIS 7.0

IIS 7.0 introduce una nuova API server su cui sono basati tutti i moduli IIS 7.0. Questa sostituisce il filtro ISAPI e le API di estensione ISAPI utilizzate nelle versioni precedenti di IIS. Per i moduli nuovi che non richiedono il supporto per le versioni precedenti, le nuove API sono più facili da utilizzare, aiutano a produrre codice più affidabile sul lato server e sono molto più potenti.

Tuttavia, IIS 7.0 rende disponibile un'opzione per supportare i filtri ISAPI e le estensioni esistenti utilizzando un livello di compatibilità implementato tramite moduli IIS 7.0 opzionali. Questo consente ai componenti ISAPI esistenti di funzionare su IIS 7.0 senza che debbano essere riscritti.

Sebbene l'utilizzo degli investimenti ISAPI esistenti agevoli la migrazione a IIS 7.0, è necessario considerare attentamente la portabilità del codice ISAPI precedente alle nuove API di IIS 7.0. Questo consente di eliminare l'overhead del livello di compatibilità ISAPI e di sfruttare i vantaggi di prestazioni che non erano disponibili per i componenti ISAPI. A seconda del lavoro eseguito dal componente ISAPI, tali vantaggi di prestazioni possono essere decisamente significativi. Ad esempio, l'API dei moduli IIS 7.0 fornisce supporto incorporato per la memorizzazione nella cache dei metadati di configurazione e di altri dati arbitrari associati a siti, applicazioni e URL, il che può accelerare notevolmente le operazioni interne del componente.

Inoltre, l'API dei moduli IIS consente ai moduli di eseguire operazioni di lunga durata in modo asincrono, come la ricezione dei dati di entità delle richieste o l'invio di risposte. L'esecuzione di queste operazioni in modo asincrono consente al server di sfruttare la scalabilità su un numero molto vasto di client simultanei (decine di migliaia), invece di limitarsi solamente a decine, o al massimo a poche centinaia, di client simultanei a causa dei limiti nel numero dei thread di richiesta. L'elaborazione asincrona può anche eliminare l'effetto dell'elaborazione su altre richieste e attività nell'applicazione, ridurre l'utilizzo della memoria e migliorare notevolmente l'utilizzo della CPU.

Oltre ai modelli specifici di miglioramento delle prestazioni, l'API nativa offre agli sviluppatori una flessibilità molto più ampia nelle attività di elaborazione delle richieste. Questo consente di migliorare la progettazione del componente server e, di conseguenza, ne migliora l'efficienza. Ad esempio, alcune operazioni di filtraggio che in precedenza richiedevano le estensioni ISAPI per i caratteri jolly e l'esecuzione di richieste di oggetto figlio possono ora essere eseguite in un modulo durante la richiesta originale, ed è anche possibile attivare la memorizzazione nella cache del kernel IIS per le risposte.

Questo potrebbe richiedere la creazione di prototipi e alcuni esperimenti per determinare la configurazione migliore che ottimizzi i benefici della migrazione. A causa delle differenze fondamentali di architettura tra ISAPI e l'API dei moduli IIS 7.0, la portabilità diretta non rappresenta necessariamente la scelta giusta. La buona notizia è che l'API dei moduli IIS 7.0 è anche più semplice da utilizzare rispetto a ISAPI, e questo rende la migrazione meno difficile.

Estendibilità del server

IIS 7.0 offre estendibilità end-to-end. Questa richiede una buona conoscenza del funzionamento del server, ma apre nuove potenti strade per migliorare le prestazioni specifiche delle applicazioni. Partendo da una buona conoscenza dell'architettura del server e dall'elaborazione delle richieste, è possibile sfruttare tale estendibilità per progettare soluzioni personalizzate di miglioramento delle prestazioni e adattarle all'applicazione, al carico di lavoro e ai requisiti hardware.

Questo può avvenire, ad esempio, sostituendo alcune delle funzionalità di IIS 7.0 incorporate con implementazioni personalizzate. Le funzionalità di IIS 7.0 sono state ampiamente ottimizzate per quando riguarda le prestazioni, ma ovviamente anche per tutti gli usi possibili. Quindi è possibile migliorare le prestazioni di determinati moduli integrando ottimizzazioni per il carico di lavoro specifico. Ad esempio, è possibile reimplementare il modulo di visualizzazione directory in modo da archiviare le visualizzazioni directory nella memoria anziché utilizzare le API del file system per enumerare i file.

In alternativa, l'estendibilità può essere utilizzata per creare nuove funzionalità di prestazioni. Gli esempi di tali funzionalità comprendono la cache di output, i moduli di compressione e varie altre cache interne.

Per determinare la necessità di una funzionalità di prestazioni personalizzata, occorre conoscere le caratteristiche delle prestazioni dell'applicazione e il carico di lavoro della stessa, oltre a sapere quale collo di bottiglia si desidera risolvere. IIS 7.0 fornisce ampio supporto di diagnostica per l'analisi delle prestazioni, che può aiutare a chiarire i requisiti e la possibile progettazione delle funzionalità.

Conclusioni

IIS 7.0 è soprattutto una versione funzionale, ma offre anche notevoli miglioramenti delle prestazioni grazie all'architettura modulare, alla configurabilità e alle nuove funzionalità di prestazioni. Questi miglioramenti possono comportare notevoli risparmi aziendali grazie al consolidamento del server e alla riduzione dei costi di larghezza di banda, oltre a migliorare l'utilizzo da parte dell'utente.

Per implementare correttamente molti di questi miglioramenti, è spesso necessario eseguire un'analisi approfondita della piattaforma applicativa attuale e comprendere bene l'architettura di IIS 7.0. Per ulteriori informazioni sull'architettura e le funzionalità di IIS 7.0 descritte in questo articolo, visitare il sito www.iis.net. Nel mio blog mvolo.com parlerò ancora delle tecniche che sfruttano attivamente IIS 7.0 per migliorare le prestazioni delle applicazioni e ridurre i costi operativi.

Mike Volodarsky è stato Program Manager del team IIS di Microsoft. Negli ultimi cinque anni, ha gestito la progettazione e lo sviluppo delle funzionalità principali di ASP.NET 2.0 e IIS 7.0. Ora si occupa dello sviluppo di tecnologie server Web avanzate per Web farm ad alte prestazioni utilizzando IIS 7.0 e Windows Server 2008. Mike è l'autore principale del libro IIS 7.0 Resource Kit e scrive regolarmente su MSDN Magazine e sul suo blog mvolo.com dedicato a IIS 7.0.