Ottimizzazione di IIS 10.0
Internet Information Services (IIS) 10.0 è incluso in Windows Server 2022. Usa un modello di processo simile a quello di IIS 8.5 e IIS 7.0. Un driver Web in modalità kernel (http.sys) riceve e instrada le richieste HTTP e soddisfa le richieste dalla cache delle risposte. I processi di lavoro registrano gli spazi secondari URL, mentre http.sys instrada la richiesta al processo appropriato (o set di processi per i pool di applicazioni).
HTTP.sys è responsabile della gestione delle connessioni e della gestione delle richieste. La richiesta può essere servita dalla cache HTTP.sys o passata a un processo di lavoro per un'ulteriore gestione. È possibile configurare più processi di lavoro, che offrono isolamento a un costo ridotto. Per altre info sul funzionamento della gestione delle richieste, vedi la figura seguente:
HTTP.sys include una cache delle risposte. Quando una richiesta corrisponde a una voce nella cache delle risposte, HTTP.sys invia la risposta della cache direttamente dalla modalità kernel. Alcune piattaforme dell'applicazione Web, ad esempio ASP.NET, forniscono meccanismi per consentire la memorizzazione di qualsiasi contenuto dinamico nella cache in modalità kernel. Il gestore di file statici in IIS 10.0 memorizza automaticamente nella cache i file richiesti di frequente in http.sys.
Poiché un server Web dispone di componenti in modalità kernel e in modalità utente, entrambi i componenti devono essere ottimizzati al fine di ottenere prestazioni ottimali. Pertanto, l'ottimizzazione di IIS 10.0 per un carico di lavoro specifico include la configurazione degli elementi seguenti:
HTTP.sys e la cache in modalità kernel associata
Processi di lavoro e IIS in modalità utente, inclusa la configurazione del pool di applicazioni
Alcuni parametri di ottimizzazione che influiscono sulle prestazioni
Le sezioni seguenti illustrano come configurare gli aspetti in modalità kernel e modalità utente di IIS 10.0.
Impostazioni in modalità kernel
Le impostazioni HTTP.sys correlate alle prestazioni rientrano in due categorie generali: gestione della cache e connessione e gestione delle richieste. Tutte le impostazioni del Registro di sistema vengono archiviate nella voce del Registro di sistema seguente:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Nota Se il servizio HTTP è già in esecuzione, è necessario riavviarlo per rendere effettive le modifiche.
Impostazioni di gestione cache
Un vantaggio offerto da HTTP.sys è una cache in modalità kernel. Se la risposta si trova nella cache in modalità kernel, è possibile soddisfare completamente una richiesta HTTP dalla modalità kernel, che riduce significativamente l’impiego della CPU per la gestione della richiesta. Tuttavia, la cache in modalità kernel di IIS 10.0 si basa sulla memoria fisica e il costo di una voce è la memoria da essa occupata.
Una voce nella cache è utile solo quando viene utilizzata. Tuttavia, la voce utilizza sempre memoria fisica, indipendentemente dal fatto che venga utilizzata o meno. È necessario valutare l'utilità di un elemento nella cache (il risparmio dalla possibilità di usarlo dalla cache) e il relativo costo (la memoria fisica occupata) per tutto il ciclo di vita della voce, considerando le risorse disponibili (CPU e memoria fisica) e i requisiti del carico di lavoro. HTTP.sys tenta di mantenere nella cache solo elementi utili, a cui si accede attivamente, ma è possibile aumentare le prestazioni del server Web ottimizzando la cache HTTP.sys per carichi di lavoro specifici.
Di seguito, sono riportate alcune impostazioni utili per la cache in modalità kernel HTTP.sys:
UriEnableCache Valore predefinito: 1
Un valore diverso da zero abilita la risposta in modalità kernel e la memorizzazione dei frammenti nella cache. Per la maggior parte dei carichi di lavoro, la cache deve rimanere abilitata. Valutare la possibilità di disabilitare la cache se si prevedono una risposta e una memorizzazione dei frammenti nella cache molto basse.
UriMaxCacheMegabyteCount Valore predefinito: 0
Un valore diverso da zero specifica la memoria massima disponibile per la cache in modalità kernel. Il valore predefinito 0 consente al sistema di regolare automaticamente la quantità di memoria disponibile per la cache.
Nota Specificare le dimensioni imposta solo il valore massimo e il sistema potrebbe non consentire la crescita della cache fino alla dimensione massima impostata.
Â
UriMaxUriBytes Valore predefinito: 262144 byte (256 kB)
Dimensione massima di una voce nella cache in modalità kernel. Risposte o frammenti di dimensioni superiori a quelle memorizzate nella cache. Se si dispone di memoria sufficiente, prendere in considerazione l'aumento del limite. Se la memoria è limitata e le voci di grandi dimensioni stanno affollandosi impedendo l’accesso di quelle più piccole, potrebbe essere utile ridurre il limite.
UriScavengerPeriod Valore predefinito: 120 secondi
La cache HTTP.sys viene analizzata periodicamente da uno scavenger e le voci a cui non si accede tra le analisi dello scavenger vengono rimosse. L'impostazione del periodo di scavenger su un valore elevato riduce il numero di analisi scavenger. Tuttavia, l'utilizzo della memoria della cache potrebbe aumentare perché le voci a cui si accede meno frequentemente possono rimanere nella cache. L'impostazione del periodo troppo basso causa analisi scavenger più frequenti e può comportare troppi scaricamenti e varianza della cache.
Impostazioni di gestione delle richieste e delle connessioni
In Windows Server 2022, HTTP.sys gestisce automaticamente le connessioni. Le impostazioni del Registro di sistema seguenti non vengono più usate:
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
Impostazioni in modalità utente
Le impostazioni in questa sezione influiscono sul comportamento del processo di lavoro IISÂ 10.0. La maggior parte di queste impostazioni è disponibile nel file di configurazione XML seguente:
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Utilizzare Appcmd.exe, il sistema di gestione IIS 10.0, il cmdlet WebAdministration o IISAdministration di PowerShell per modificarli. La maggior parte delle impostazioni viene rilevata automaticamente e non richiede un riavvio dei processi di lavoro IIS 10.0 o del server applicazione Web. Per altre informazioni sul file applicationHost.config, vedere Introduzione ad ApplicationHost.config.
Impostazione della CPU ideale per l'hardware NUMA
A partire da Windows Server 2016, IIS 10.0 supporta l'assegnazione automatica della CPU ideale per i thread del pool di thread per migliorare le prestazioni e la scalabilità sull'hardware NUMA. Questa funzionalità è abilitata per impostazione predefinita e può essere configurata tramite la chiave del Registro di sistema seguente:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
Con questa funzionalità abilitata, Gestione thread IIS fa il massimo sforzo per distribuire uniformemente i thread del pool di thread IIS in tutte le CPU in tutti i nodi NUMA in base ai carichi correnti. In generale, è consigliabile mantenere invariata tale impostazione predefinita per l'hardware NUMA.
Nota L'impostazione ideale della CPU è diversa dalle impostazioni di assegnazione del nodo NUMA del processo di lavoro (numaNodeAssignment e numaNodeAffinityMode) introdotte in Impostazioni CPU per un pool di applicazioni. L'impostazione ideale della CPU influisce sul modo in cui IIS distribuisce i thread del pool di thread, mentre le impostazioni di assegnazione del nodo NUMA del processo di lavoro determinano in quale nodo NUMA viene avviato un processo di lavoro.
Impostazioni del comportamento della cache in modalità utente
In questa sezione vengono descritte le impostazioni che influiscono sul comportamento di memorizzazione nella cache in IIS 10.0. La cache in modalità utente viene implementata come modulo in ascolto degli eventi di memorizzazione nella cache globale generati dalla pipeline integrata. Per disabilitare completamente la cache in modalità utente, rimuovere il modulo FileCacheModule (cachfile.dll) dall'elenco dei moduli installati nella sezione di configurazione system.webServer/globalModules in applicationHost.config.
system.webServer/caching
| Attributo | Descrizione | Default |
|---|---|---|
| Attivato | Disabilita la cache IIS in modalità utente quando è impostata su Falso. Quando la frequenza di riscontri nella cache è molto ridotta, è possibile disabilitare completamente la cache per evitare il sovraccarico associato al percorso del codice della cache. La disabilitazione della cache in modalità utente non disabilita la cache in modalità kernel. | Vero |
| enableKernelCache | Disabilita la cache in modalità kernel quando è impostata su Falso. | Vero |
| maxCacheSize | Limita le dimensioni della cache in modalità utente IIS alle dimensioni specificate in megabyte. IIS regola il valore predefinito a seconda della memoria disponibile. Scegliere attentamente il valore in base alle dimensioni del set di file a cui si accede di frequente rispetto alla quantità di RAM o allo spazio indirizzi del processo IIS. | 0 |
| maxResponseSize | Memorizza nella cache i file fino alle dimensioni specificate. Il valore effettivo dipende dal numero e dalle dimensioni dei file più grandi nel set di dati rispetto alla RAM disponibile. La memorizzazione nella cache di file di grandi dimensioni spesso richiesti può ridurre l'utilizzo della CPU, l'accesso al disco e le latenze associate. | 262144 |
Impostazioni del comportamento di compressione
A partire dalla versione 7.0, IIS comprime il contenuto statico per impostazione predefinita. Inoltre, quando è installato DynamicCompressionModule la compressione del contenuto dinamico è abilitata per impostazione predefinita. La compressione riduce l'utilizzo della larghezza di banda, ma aumenta l'utilizzo della CPU. Se possibile, il contenuto compresso viene memorizzato nella cache in modalità kernel. A partire dalla versione 8.5, IIS consente di controllare la compressione in modo indipendente per il contenuto statico e quello dinamico. Il contenuto statico si riferisce in genere al contenuto che non cambia, ad esempio file GIF o HTM. Il contenuto dinamico viene solitamente generato da script o codice nel server, ovvero pagine ASP.NET. È possibile personalizzare la classificazione di qualsiasi estensione specifica come statica o dinamica.
Per disabilitare completamente la compressione, rimuovere StaticCompressionModule e DynamicCompressionModule dall'elenco dei moduli nella sezione system.webServer/globalModules in applicationHost.config.
system.webServer/httpCompression
| Attributo | Descrizione | Default |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Abilita o disabilita la compressione se l'utilizzo della CPU percentuale corrente supera o è inferiore ai limiti specificati. A partire da IIS 7.0, la compressione viene disabilitata automaticamente se la CPU con stato stabile aumenta al di sopra della soglia di disabilitazione. La compressione è abilitata se la CPU scende al di sotto della soglia di abilitazione. |
rispettivamente 50, 100, 50 e 90 |
| directory | Specifica la directory in cui le versioni compresse dei file statici vengono archiviate temporaneamente e memorizzate nella cache. È consigliabile spostare questa directory dall'unità di sistema se vi si accede di frequente. | %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files |
| doDiskSpaceLimiting | Specifica se esiste un limite per la quantità di spazio su disco che tutti i file compressi possono occupare. I file compressi vengono archiviati nella directory di compressione specificata dall'attributo della directory. | Vero |
| maxDiskSpaceUsage | Specifica il numero di byte di spazio su disco che i file compressi possono occupare nella directory di compressione. Questa impostazione potrebbe essere aumentata se le dimensioni totali di tutto il contenuto compresso sono troppo grandi. |
100 MB |
system.webServer/urlCompression
| Attributo | Descrizione | Default |
|---|---|---|
| doStaticCompression | Specifica se il contenuto statico è compresso. | Vero |
| doDynamicCompression | Specifica se il contenuto dinamico è compresso. | Vero |
Nota
Per i server che eseguono IIS 10.0 con utilizzo basso della CPU, è consigliabile abilitare la compressione per il contenuto dinamico, soprattutto se le risposte sono di grandi dimensioni. Questa operazione deve essere eseguita prima in un ambiente di test per valutare l'effetto sull'utilizzo della CPU dalla baseline.
Ottimizzazione dell'elenco di documenti predefinito
Il modulo di documento predefinito gestisce le richieste HTTP per la radice di una directory e le converte in richieste per un file specifico, ad esempio Default.htm o Index.htm. In media, circa il 25% di tutte le richieste su Internet passa attraverso il percorso del documento predefinito. Ciò varia in modo significativo per i singoli siti. Quando una richiesta HTTP non specifica un nome di file, il modulo documento predefinito cerca nell'elenco dei documenti predefiniti consentiti ogni nome nel file system. Ciò può influire negativamente sulle prestazioni, soprattutto se il raggiungimento del contenuto richiede un round trip di rete o il tocco di un disco.
È possibile evitare il sovraccarico disabilitando in modo selettivo i documenti predefiniti e riducendo o ordinando l'elenco dei documenti. Per i siti Web che utilizzano un documento predefinito, è consigliabile ridurre l'elenco solo ai tipi di documento predefiniti utilizzati. Inoltre, ordinare l'elenco in modo che inizi con il nome di file di documento predefinito a cui si accede più di frequente.
È possibile impostare in modo selettivo il comportamento predefinito del documento su URL specifici personalizzando la configurazione all'interno di un tag location in applicationHost.config oppure inserendo un file web.config direttamente nella directory del contenuto. Ciò consente un approccio ibrido, che abilita i documenti predefiniti solo laddove sono necessari e imposta l'elenco sul nome file corretto per ciascun URL.
Per disabilitare completamente i documenti predefiniti, rimuovere DefaultDocumentModule dall'elenco dei moduli nella sezione system.webServer/globalModules in applicationHost.config.
system.webServer/defaultDocument
| Attributo | Descrizione | Default |
|---|---|---|
| Enabled | Specifica che i documenti predefiniti sono abilitati. | Vero |
elemento <files> |
Specifica i nomi di file configurati come documenti predefiniti. | L'elenco predefinito è Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm e Default.aspx. |
Registrazione binaria centrale
Quando la sessione del server include numerosi gruppi di URL, il processo di creazione di centinaia di file di log formattati per singoli gruppi di URL e la scrittura dei dati di log in un disco può consumare rapidamente risorse preziose di CPU e memoria, creando così problemi di prestazioni e scalabilità. La registrazione binaria centralizzata riduce al minimo la quantità di risorse di sistema utilizzate per la registrazione, fornendo allo stesso tempo dati di log dettagliati per le organizzazioni che lo richiedono. L'analisi dei log in formato binario richiede uno strumento di post-elaborazione.
È possibile abilitare la registrazione binaria centrale impostando l'attributo centralLogFileMode su CentralBinary e impostando l'attributo abilitato su Vero. Valutare la possibilità di spostare la posizione del file di log centrale dalla partizione di sistema e in un'unità di registrazione dedicata per evitare conflitti tra le attività di sistema e le attività di registrazione.
system.applicationHost/log
| Attributo | Descrizione | Default |
|---|---|---|
| centralLogFileMode | Specifica la modalità di registrazione per un server. Modificare questo valore in CentralBinary per abilitare la registrazione binaria centrale. | Sito |
system.applicationHost/log/centralBinaryLogFile
| Attributo | Descrizione | Default |
|---|---|---|
| Enabled | Specifica se la registrazione binaria centrale è abilitata. | Falso |
| directory | Specifica la directory in cui vengono scritte le voci di log. | %SystemDrive%\inetpub\logs\LogFiles |
Ottimizzazione di applicazioni e siti
Le impostazioni seguenti sono correlate alle ottimizzazioni del pool di applicazioni e del sito.
system.applicationHost/applicationPools/applicationPoolDefaults
| Attributo | Descrizione | Default |
|---|---|---|
| queueLength | Indica a HTTP.sys il numero di richieste in coda per un pool di applicazioni prima che le richieste future vengano rifiutate. Quando viene superato il valore di questa proprietà, IIS rifiuta le richieste successive restituendo un errore 503. In caso di errori 503, valutarne l’ampliamento per le applicazioni che comunicano con archivi dati back-end a latenza elevata. |
1000 |
| enable32BitAppOnWin64 | Se Vero, consente l'esecuzione di un'applicazione a 32 bit in un computer dotato di un processore a 64 bit. Valutare la possibilità di abilitare la modalità a 32 bit se l'utilizzo della memoria risulta problematica. Poiché le dimensioni del puntatore e le dimensioni delle istruzioni sono inferiori, le applicazioni a 32 bit utilizzano meno memoria rispetto a quelle a 64 bit. Lo svantaggio dell'esecuzione di applicazioni a 32 bit in un computer con processore a 64 bit è che lo spazio degli indirizzi in modalità utente è limitato a 4 GB. |
Falso |
system.applicationHost/sites/VirtualDirectoryDefault
| Attributo | Descrizione | Default |
|---|---|---|
| allowSubDirConfig | Specifica se IIS cerca i file web.config nelle directory del contenuto inferiori al livello corrente (Vero) oppure non cerca i file web.config nelle directory del contenuto inferiori al livello corrente (Falso). Imponendo una semplice limitazione, che consente la configurazione solo nelle directory virtuali, IIS 10.0 può sapere che, a meno che /<name>.htm non sia una directory virtuale, non deve cercare un file di configurazione. Ignorare le operazioni aggiuntive sui file può migliorare significativamente le prestazioni dei siti Web con un set molto elevato di contenuto statico a cui si accede in modo casuale. | Vero |
Gestione dei moduli IIS 10.0
IIS 10.0 è stato inserito in più moduli espandibili dall'utente per supportare una struttura modulare. Questa fattorizzazione ha un costo ridotto. Per ogni modulo la pipeline integrata deve richiamare il modulo per ciascun evento ad esso pertinente. Ciò avviene indipendentemente dal fatto che il modulo debba eseguire una qualsivoglia operazione. È possibile risparmiare cicli di CPU e memoria rimuovendo tutti i moduli non rilevanti per un determinato sito Web.
Un server Web ottimizzato per file statici semplici può includere solo i cinque moduli seguenti: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule e HttpLoggingModule.
Per rimuovere moduli da applicationHost.config, rimuovere tutti i riferimenti al modulo dalle sezioni system.webServer/handlers e system.webServer/modules, oltre a rimuovere la dichiarazione del modulo in system.webServer/globalModules.
Impostazioni ASP classiche
Il costo principale dell'elaborazione di una richiesta ASP classica include l'inizializzazione di un motore di script, la compilazione dello script ASP richiesto in un modello ASP e l'esecuzione del modello nel motore di script. Anche se il costo di esecuzione del modello dipende dalla complessità dello script ASP richiesto, il modulo ASP classico IIS può memorizzare nella cache i motori di script nella memoria e i modelli di cache nella memoria e su disco (solo se la cache dei modelli in memoria è sovrabbondante) per migliorare le prestazioni negli scenari associati alla CPU.
Le impostazioni seguenti vengono utilizzate per configurare la cache classica dei modelli ASP e la cache del motore di script e non influiscono sulle impostazioni ASP.NET.
system.webServer/asp/cache
| Attributo | Descrizione | Default |
|---|---|---|
| diskTemplateCacheDirectory | Il nome della directory utilizzata da ASP per archiviare i modelli compilati quando la cache in memoria è sovrabbondante. Raccomandazione: impostare una directory che non è molto utilizzata, ad esempio un'unità non condivisa con il sistema operativo, il log IIS o altri contenuti a cui si accede di frequente. |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | Specifica il numero massimo di modelli ASP compilati che possono essere memorizzati nella cache su disco. Raccomandazione: impostare sul valore massimo 0x7FFFFFFF. |
2000 |
| scriptFileCacheSize | Questo attributo specifica il numero massimo di modelli ASP compilati che possono essere memorizzati nella cache in memoria. Raccomandazione: impostare almeno sul numero di script ASP richiesti di frequente gestiti da un pool di applicazioni. Se possibile, impostare su tutti i modelli ASP consentiti per i limiti di memoria. |
500 |
| scriptEngineCacheMax | Specifica il numero massimo di motori di script che verranno memorizzati nella cache in memoria. Raccomandazione: impostare almeno sul numero di script ASP richiesti di frequente gestiti da un pool di applicazioni. Se possibile, impostare su tutti i motori di script consentiti dal limite di memoria. |
250 |
system.webServer/asp/limits
| Attributo | Descrizione | Default |
|---|---|---|
| processorThreadMax | Specifica il numero massimo di thread di lavoro per processore che ASP è in grado di creare. Incrementare tale valore se l'impostazione corrente non è sufficiente per gestire il carico, cosa che può determinare errori quando ha in carico le richieste oppure causare un utilizzo insufficiente delle risorse della CPU. | 25 |
system.webServer/asp/comPlus
| Attributo | Descrizione | Default |
|---|---|---|
| executeInMta | Impostare su Vero se vengono rilevati errori o problematiche mentre IIS ha in carico il contenuto ASP. Ciò può verificarsi, ad esempio, quando si ospitano più siti isolati in cui ogni sito viene eseguito nel proprio processo di lavoro. Gli errori vengono in genere segnalati da COM+ nel Visualizzatore eventi. Questa impostazione abilita il modello apartment multithread in ASP. | Falso |
Impostazione della concorrenza di ASP.NET
ASP.NET 3.5
Per impostazione predefinita, ASP.NET limita la concorrenza di richieste per ridurre il consumo di memoria a stati stabili nel server. Le applicazioni con concorrenza elevata potrebbero necessitare della modifica di alcune impostazioni per migliorare le prestazioni complessive. È possibile modificare tale impostazione nel file aspnet.config:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
L'impostazione seguente è utile per utilizzare completamente le risorse di un sistema:
maxConcurrentRequestPerCpu Valore predefinito: 5000
Questa impostazione limita il numero massimo di richieste di ASP.NET in esecuzione simultanea all’interno di un sistema. Il valore predefinito è conservativo per ridurre il consumo di memoria delle applicazioni ASP.NET. Prendere in considerazione l'aumento di tale limite nei sistemi dove vengono eseguite applicazioni che svolgono operazioni di I/O lunghe e sincrone. In caso contrario, quando viene usata l'impostazione predefinita, è possibile che gli utenti riscontrino una latenza elevata a causa di errori di accodamento o di richieste, che sono dovuti al superamento dei limiti di coda in caso di caricamento elevato.
ASP.NET 4.6
Oltre all'impostazione maxConcurrentRequestPerCpu, ASP.NET 4.7 fornisce anche impostazioni per migliorare le prestazioni nelle applicazioni che si basano principalmente sull'operazione asincrona. L'impostazione può essere modificata nel file aspnet.config.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Valore predefinito: 90 La richiesta asincrona presenta alcuni problemi di scalabilità quando viene eseguito un carico molto grande (oltre le capacità dell’hardware) in uno scenario di questo tipo. Il problema è dovuto alla natura dell'allocazione in scenari asincroni. In queste condizioni, l'allocazione verrà eseguita all'avvio dell'operazione asincrona e risulterà utilizzata al termine dell'operazione stessa. A quel punto, è molto probabile che gli oggetti siano stati spostati alla generazione 1 o 2 da GC. In questo caso, l'aumento del carico mostrerà un incremento della richiesta al secondo (rps) fino a un punto dato. Dopo aver superato questo punto, il tempo impiegato in GC inizierà a diventare problematico e le rps inizieranno ad abbassarsi, con un effetto di ridimensionamento negativo. Per risolvere il problema, quando l'utilizzo della CPU supera l'impostazione percentCpuLimit, le richieste verranno inviate alla coda nativa ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu Valore predefinito: 100 La limitazione della CPU (impostazione percentCpuLimit) non si basa sul numero di richieste, ma sull’incidenza che esse hanno in termini di consumo. Di conseguenza, potrebbero esserci solo alcune richieste a elevato utilizzo di CPU che causano un backup nella coda nativa, senza alcun modo per svuotarlo se non per le richieste in ingresso. Per risolvere questo problema, è possibile usare percentCpuLimitMinActiveRequestPerCpu al fine di garantire che venga gestito un numero minimo di richieste prima che la limitazione venga avviata.
Opzioni di riciclo e processo di lavoro
È possibile configurare le opzioni per riciclare i processi di lavoro IIS e fornire soluzioni pratiche a situazioni o eventi gravi senza richiedere l'intervento o la reimpostazione di un servizio o di un computer. Tali situazioni ed eventi includono perdite di memoria, aumento del carico di memoria o processi di lavoro inattivi o inerti. In condizioni normali, le opzioni di riciclo potrebbero non essere necessarie e il riciclo può essere disattivato oppure è possibile riconfigurare il sistema perché il riciclo venga effettuato molto raramente.
È possibile abilitare il riciclo dei processi per una determinata applicazione aggiungendo attributi all'elemento recycling/periodicRestart. L'evento di riciclo può essere attivato da diversi eventi, tra cui l'utilizzo della memoria, un numero fisso di richieste e un periodo di tempo fisso. Quando un processo di lavoro viene riciclato, le richieste in coda e in esecuzione vengono drenate e viene avviato contestualmente un nuovo processo per gestire nuove richieste. L'elemento recycling/periodicRestart è “per applicazione”, il che significa che ogni attributo nella tabella seguente viene partizionato per ciascuna applicazione.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Attributo | Descrizione | Default |
|---|---|---|
| memory | Abilitare il riciclo del processo se il consumo di memoria virtuale supera il limite specificato in kilobyte. Si tratta di un'impostazione utile per i computer a 32 bit, con uno ridotto spazio indirizzi di 2 GB. Può aiutare a evitare richieste non riuscite a causa di errori di memoria insufficiente. | 0 |
| privateMemory | Abilitare il riciclo dei processi se le allocazioni della memoria privata superano un limite specificato in kilobyte. | 0 |
| requests | Abilitare il riciclo dei processi dopo un determinato numero di richieste. | 0 |
| time | Abilitare il riciclo dei processi dopo un periodo di tempo specificato. | 29:00:00 |
Ottimizzazione della pagina del processo di lavoro dinamico
A partire da Windows Server 2012 R2, IIS offre la possibilità di configurare il processo di lavoro da sospendere dopo un certo periodo di inattività (oltre all'opzione di interruzione, in essere a partire da IIS 7).
Lo scopo principale di entrambe le funzionalità di interruzione del processo di lavoro per inattività e di interruzione del processo di lavoro per inerzia è quello di risparmiare utilizzo della memoria sul server, poiché un sito può consumare molta memoria anche se si trova in una situazione passiva. A seconda della tecnologia impiegata nel sito (contenuto statico, ASP.NET o altri framework), la memoria utilizzata può andare in ogni caso da circa 10 MB a centinaia di MB, e questo significa che se il server è configurato con molti siti, capire le impostazioni più efficaci per i siti gestiti può migliorare notevolmente le prestazioni dei siti attivi e di quelli sospesi.
Prima di entrare nelle specifiche, è necessario tenere presente che se non sono presenti vincoli di memoria, è probabilmente preferibile impostare semplicemente i siti perché non vengano mai sospesi o interrotti. Dopotutto, non ha molto valore terminare un processo di lavoro se è l'unico nel computer.
Nota
Nel caso in cui il sito esegua un codice instabile, ad esempio un codice con una perdita di memoria o altrimenti instabile, l'impostazione del sito da interrompere per inattività può essere un'alternativa rapida alla correzione del bug del codice. Non si tratta di qualcosa da consigliare, ma nei momenti di difficoltà l’utilizzo di questa funzionalità potrebbe risultare più efficace come meccanismo di pulizia, mentre una soluzione più duratura è in funzione.
Un altro fattore da considerare è che se il sito utilizza molta memoria, il processo di sospensione stesso richiede un pedaggio in termini di consumo, perché il computer deve scrivere i dati utilizzati dal processo di lavoro su disco. Se il processo di lavoro utilizza una grande quantità di memoria, la sospensione potrebbe risultare più costosa del dover attendere l'avvio del backup.
Per ottimizzare la funzionalità di sospensione del processo di lavoro, è necessario esaminare i siti in ogni pool di applicazioni e decidere quali devono essere sospesi, quali devono essere interrotti e quali devono rimanere attivi a tempo indeterminato. Per ogni azione e ogni sito è necessario stabilire il periodo di timeout ideale.
Idealmente, i siti che vanno configurati per la sospensione o l’interruzione sono quelli che ricevono visite ogni giorno, ma non in numero tale da garantirne il mantenimento in attività tutto il tempo. Si tratta solitamente di siti con circa 20 visitatori unici al giorno o anche in numero minore. È possibile analizzare i modelli di traffico usando i file di log del sito e calcolare così il traffico giornaliero medio.
Tenere presente che, una volta che un utente specifico si connette al sito, in genere vi rimarrà per almeno un po', effettuando richieste aggiuntive, e quindi il solo conteggio delle richieste giornaliere potrebbe non riflettere accuratamente i modelli di traffico reali. Per ottenere una lettura più accurata, è possibile utilizzare anche uno strumento, ad esempio Microsoft Excel, per calcolare il tempo medio che intercorre tra le richieste. Ad esempio:
| Numero | Richiesta URL | Ora della richiesta | Delta |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 13:00 |
| 8 | /rest/Services/CachedServices/Silverlight_basemap...¦. | 12:51 | 0:01 |
| 9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
| 10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
| 11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 00:00 |
| 12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
La parte difficile, però, è capire quale impostazione applicare perché abbia un senso. In questo caso, il sito ottiene una serie di richieste da parte degli utenti e la tabella precedente mostra che un totale di 4 sessioni univoche si è verificato nell’arco di periodo di 4 ore. Con le impostazioni predefinite per la sospensione del processo di lavoro del pool di applicazioni, il sito viene interrotto dopo il timeout predefinito di 20 minuti, il che significa che ognuno di questi utenti riscontra il ciclo di spin-up del sito. Ciò lo rende un candidato ideale per la sospensione del processo di lavoro, perché per la maggior parte del tempo il sito è inattivo: sospenderlo consente di risparmiare risorse e permette agli utenti di raggiungere il sito in maniera quasi istantanea.
Una nota finale estremamente importante è che le prestazioni del disco sono fondamentali per questa funzionalità. Poiché il processo di sospensione e riattivazione comporta la scrittura e la lettura di grandi quantità di dati nel disco rigido, è consigliabile utilizzare un disco veloce per questa operazione. Le unità SSD (Solid State Drive) sono ideali e altamente consigliate per operazioni di questo tipo. È consigliabile assicurarsi che il file di pagina di Windows sia archiviato in esso (se il sistema operativo stesso non è installato nell'unità SSD, configurare il sistema operativo in modo da poter spostare il file di pagina nell’unità).
Indipendentemente dal fatto che si utilizzi o meno un'unità SSD, è consigliabile inoltre correggere le dimensioni del file di pagina per consentirvi la scrittura dei dati di pageout senza ridimensionamento dei file. Il ridimensionamento dei file di pagina può verificarsi quando il sistema operativo deve archiviare i dati nel file di pagina, perché per impostazione predefinita Windows è configurato per regolare automaticamente le dimensioni in base alle esigenze. Impostando le dimensioni su un valore fisso, è possibile impedire il ridimensionamento e migliorare notevolmente le prestazioni.
Per configurare una dimensione predefinita del file di pagina, è necessario calcolarne le dimensioni ideali, che dipendono dal numero di siti che verranno sospesi e dalla quantità di memoria utilizzata. Se la media è di 200 MB per un processo di lavoro attivo e si dispone di 500 siti nei server che verranno sospesi, il file di pagina deve essere almeno (200 * 500) MB rispetto alle dimensioni di base del file di pagina (quindi base + 100 GB nell'esempio riportato).
Nota
Quando i siti vengono sospesi, utilizzeranno circa 6 MB ciascuno: in questo caso l'utilizzo della memoria, nel caso tutti i siti vengano sospesi, sarebbe di circa 3 GB. In realtà, però, è probabile che non verranno mai tutti sospesi dall'utente allo stesso tempo.
Parametri di ottimizzazione di Transport Layer Security
L'utilizzo di Transport Layer Security (TLS) impone pedaggi aggiuntivi in termini consumo per la CPU. Il componente di TLS che consuma di più è quello relativo allo stabilimento di una sessione, perché comporta un handshake completo. Anche riconnessione, crittografia e decrittazione vanno a pesare in termini di consumo ulteriore. Per migliorare le prestazioni di TLS, eseguire le operazioni seguenti:
Abilitare keep-alive HTTP per le sessioni TLS. In questo modo si eliminano i costi di definizione della sessione.
Riutilizzare le sessioni quando appropriato, in particolare con il traffico non keep-alive (da non mantenere attivo).
Applicare in modo selettivo la crittografia solo alle pagine o alle parti del sito che ne hanno bisogno, piuttosto che all'intero sito.
Nota
- Le chiavi di maggiori dimensioni offrono maggiore sicurezza, ma consumano anche più tempo della CPU.
- Potrebbe non essere necessario crittografare tutti i componenti. Tuttavia, la combinazione di HTTP normale e HTTPS potrebbe risultare in una notifica popup in cui si avvisa che non tutti i contenuti nella pagina sono protetti.
Internet Server Application Programming Interface (ISAPI)
Non sono necessari parametri di ottimizzazione speciali per le applicazioni ISAPI. Se si scrive un'estensione ISAPI privata, assicurarsi che sia scritta tenendo in considerazione le prestazioni e l'utilizzo delle risorse.
Linee guida per l'ottimizzazione del codice gestito
Il modello di pipeline integrata in IIS 10.0 consente un elevato grado di flessibilità ed estendibilità. I moduli personalizzati implementati nel codice nativo o gestito possono essere inseriti nella pipeline oppure possono sostituire i moduli esistenti. Anche se questo modello di estendibilità offre praticità e semplicità, è consigliabile prestare attenzione prima di inserire nuovi moduli gestiti che si associano agli eventi globali. L'aggiunta di un modulo gestito globale implica che tutte le richieste, incluse le richieste di file statici, devono andare a toccare il codice gestito. I moduli personalizzati sono soggetti a eventi come Garbage Collection. Inoltre, i moduli personalizzati aggiungono consumi significativi della CPU a causa del marshalling dei dati tra codice nativo e gestito. Se possibile, sarebbe necessario impostare preCondition su managedHandler per il modulo gestito.
Per ottenere prestazioni di avvio a freddo migliori, assicurarsi di precompilare il sito Web ASP.NET o sfruttare la funzionalità di inizializzazione dell'applicazione IIS per “riscaldare” l'applicazione.
Se lo stato della sessione non è necessario, assicurarsi di disattivarlo per ogni singola pagina.
Se sono presenti molte operazioni di I/O associate, provare a utilizzare la versione asincrona delle API pertinenti, che offrono una scalabilità molto migliore.
Inoltre, l'utilizzo della cache di output migliora anche le prestazioni del sito Web.
Quando si eseguono più host che contengono ASP.NET script in modalità isolata (un pool di applicazioni per sito), monitorare l'utilizzo della memoria. Assicurarsi che il server disponga di RAM sufficiente per il numero previsto di pool di applicazioni in esecuzione simultanea. Prendere in considerazione l'utilizzo di più domini di applicazione invece di più processi isolati.
Altri problemi che influiscono sulle prestazioni di IIS
I problemi seguenti possono influire sulle prestazioni di IIS:
Installazione di filtri che non riconoscono la cache
L'installazione di un filtro che non è compatibile con HTTP-cache fa sì che IIS disabiliti completamente la memorizzazione nella cache, con conseguenti prestazioni scarse. I filtri ISAPI scritti prima della versione IIS 6.0 possono causare tale comportamento.
Richieste CGI (Common Gateway Interface)
Per motivi prestazionali, l'utilizzo di applicazioni CGI per la gestione delle richieste non è consigliato con IIS. La creazione e l'eliminazione di processi CGI comportano spesso un sovraccarico significativo. Le alternative migliori includono l'uso di FastCGI, script dell'applicazione ISAPI e script ASP o ASP.NET. L'isolamento è disponibile per ognuna di tali opzioni.