Applicazione ASP.NET IIS7: 2 app identiche in 2 pool di app identici, 1 è reattivo e 1 no

Ho un'app Web ASP.NET (v4.0) installata in una directory virtuale (come applicazione) e ospitata nel suo pool di app. Questo si ripete per ogni istanza dell'app (ovvero per cliente).

I pool di app sono in modalità integrata (non classica) e LoadUserProfile è impostato su true. Altrimenti, impostazioni predefinite.

Ogni istanza ha attualmente la propria copia del codice / config e la propria cartella di dati (lettura / scrittura del file di base).

1 istanza di questa app funziona bene (l'operazione utilizzata per il confronto richiede ~ 4 secondi). Ogni altra istanza viene eseguita lentamente (da 10 a 25 secondi per la stessa operazione).

Se sposto l'istanza più lenta nel pool di app "più veloce", quell'istanza prende vita. Se sposto l'istanza più veloce nel pool di app più lento, quell'istanza rallenta a una ricerca per indicizzazione.

I pool di app sono stati creati allo stesso modo inizialmente, manualmente. In seguito ho usato la routine di copia PowerShell per garantire una copia esatta del pool di app più veloce e comunque lo stesso comportamento. Il confronto dei file apppool.config mostra che sono identici, salvo le assegnazioni di directory virtuali.

Non ci sono risorse condivise che vengono bloccate, per quanto ne so, e l'ho verificato spegnendo il pool di app performanti e riavviando ... slow è ancora lento, quindi quando riavvio quel pool di app (quindi è caricato ultimo) è ancora più veloce ...

Per isolare ulteriormente il problema, suggerirei di eseguire Wireshark (o altro analizzatore di pacchetti di scelta) sul sistema host, per due sessioni. Presuppongo che a ogni pool di app sia assegnato un IP univoco o una porta univoca.

Innanzitutto ottieni le prestazioni di base filtrando sull'IP: porta del tuo pool di app veloce. Guarda come appare il traffico da e verso l'app in condizioni "normali".

Alla seconda esecuzione, dovrai acquisire il traffico dal pool di app lento / che non risponde. Se tutto il routing di rete e simili è corretto fino alla scatola, dovresti vedere richieste ripetute in una direzione, molto probabilmente all'app da altrove, MA se l'app è qualcosa che fa molte richieste a un altro server, il tuo traffico potrebbe essere pesante su uscita invece di ingresso.

Questo test ti dirà se il problema è all'interno dell'app o se sono i problemi relativi a TCP / IP che provocano il timeout delle richieste dell'app a causa di comunicazioni basse / assenti.

Correlare i timestamp dei test con i registri eventi del server e (se applicabile) i registri del tracciamento e si dovrebbe essere in grado di concentrarsi sul problema.

La traccia richieste non riuscite (FRT) sarà lo strumento migliore per rintracciarlo. Mostrerà la pipeline e il tempo impiegato per completare ogni passaggio. Ciò dovrebbe indicare se si tratta di qualcosa all'interno della parte asp.net o se è qualcosa all'interno della pipeline IIS stessa.

Per configurare FRT, da IIS a livello di sito creare una regola FRT con un intervallo di stato http di 200-999 e assicurarsi di abilitare FRT (è un passaggio separato dal riquadro azioni).

Quindi riprodurre il problema e guardare i file generati (% SystemDrive% \ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}). Aprili in Internet Explorer.

Quando IIS ritarda per lunghi periodi di tempo senza una ragione apparente, di solito significa che è in attesa di un timeout di un servizio esterno. Quando lo fa, prova un altro approccio. Del resto, questo vale per qualsiasi cosa in Windows o Linux. Il primo sospetto per me in queste situazioni è sempre la configurazione della risoluzione dei nomi di rete. È colpevole fino a prova contraria.

Questo può essere ricreato con un utente che colpisce uno dei siti duplicati? Sarebbe bene sapere cosa stanno facendo la CPU e i dischi quando si ricrea il tempo di risposta di 10-20 secondi. Se sembra che non succeda molto durante i 10-20 secondi, è necessario controllare i nomi di associazione e la risoluzione dei nomi per i nomi associati. Se la CPU o i dischi si stanno masticando, dovrai capire quale processo sta lavorando troppo e perché.

Per favore pubblica i tuoi risultati, sono curioso.

PS Vorrei anche controllare la risoluzione dei nomi e l'accesso a tutti i servizi di autenticazione che potrebbero essere in gioco. Ad esempio, se è necessario consultare il server del dominio assicurarsi che il primo server DNS nell'elenco sia il server DNS per il dominio.

Questa non è la soluzione, ma lavoreremo per essa;

1. Esegui IISRESET (durante le ore di manutenzione) o uccidi il W3WP che appartiene al pool di app che non risponde

2. Avvia l'applicazione

3. Mentre non risponde, prendi un file di dump di W3WP che appartiene al pool di app lento. Utilizzare Process Explorer o Task Manager per creare un file di dump

4. Prendi mscordacwks.dll e mscorwks.dll da sotto C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX

5. Comprimi e carica questi file da qualche parte da dove posso scaricare.