Guida operativa basata su un caso verificato. Ritorno in servizio verificato dopo un avvio IIS lento: code di richieste ExecuteRequestHandler, app pool attivi e test HTTP ripetuti.
Problema
Dopo bonifica e riavvio di un frontend IIS, i servizi W3SVC e WAS risultavano attivi ma alcune richieste HTTP andavano in timeout. Un controllo frettoloso avrebbe potuto far rientrare un nodo non pronto nel bilanciatore.
Dati significativi
Le richieste pendenti apparivano nello stadio ExecuteRequestHandler del modulo AspNetCoreModuleV2. I processi worker erano avviati e la CPU era molto bassa, mentre le richieste impiegavano decine di secondi.
Comandi utili
%windir%\system32\inetsrv\appcmd.exe list apppool
%windir%\system32\inetsrv\appcmd.exe list wp
%windir%\system32\inetsrv\appcmd.exe list requests
sc.exe query W3SVC
sc.exe query WASEseguire i controlli da una console amministrativa; l’elenco delle richieste deve essere correlato ai log applicativi .NET.
Riscaldamento controllato
Senza reinserire subito il nodo nel pool, abbiamo ripetuto richieste HTTP dirette ai principali VirtualHost applicativi tramite il relativo header Host. Le prime verifiche avevano registrato timeout; più tardi tre cicli consecutivi non ne hanno mostrati.
Soglie di rientro
curl --connect-timeout 2 --max-time 8 \n -H 'Host: NOME_SITO' -o /dev/null \n -w '%{http_code} %{time_total}\n' http://IP_BACKEND/Confrontare i codici e i tempi con gli altri frontend sani. In questo caso le risposte finali erano nell’ordine delle decine di millisecondi.
Controllo successivo
L'elenco richieste IIS risultava vuoto e non c'erano più timeout. Solo dopo questi controlli il nodo è stato reinserito sui proxy con backup, test sintattici e reload.
Nota
Un warm-up lento può anche nascondere dipendenze esterne o regressioni applicative: l'esito positivo non significa ignorare i log o disattivare i timeout.
Approfondimenti correlati
Comandi e percorsi riportano segnaposto generici; verificare versioni e backup prima di applicarli in produzione.