2012-01-19 12 views
8

Qui è il mio problema:IIS7 smette di funzionare dopo 5 richieste

ho appena stati introdotti in un imponente progetto # asp.net C e sono stato accusato di fissare alcuni problemi di prestazioni (non la mia area di competenza). Più specificamente dopo 5 - 7 reindirizzamenti/ajax chiama il server Web si blocca e l'intera pagina (e eventualmente il browser) si blocca.

Non penso che questo sia un problema di codifica in quanto ho impostato i punti di interruzione in poche pagine (metodo Page_Load) e dopo le 5 richieste non raggiunge nemmeno i punti di interruzione.

Non credo sia collegato a this issue poiché ho aumentato le connessioni massime del browser per parametro server e ho ottenuto lo stesso comportamento. Inoltre, dopo queste 5 richieste in un browser IE, l'applicazione smette di funzionare anche in FF.

Questo non è un problema di risorse poiché il processo w3wp.exe non supera mai la memoria di 500 MB.

Una cosa che ho notato usando Fiddler e altri strumenti per monitorare le richieste è che il server impiega molto tempo durante il caricamento dei file di immagine (png, jpg). Non so se questo è rilevante.

Ho abilitato la traccia delle richieste non riuscite sul server e l'unica cosa che ho notato è che alcune richieste falliscono con un errore 401 anche se ho imposto l'autenticazione anonima per abilitare. Ecco il messaggio esatto

MODULE_SET_RESPONSE_ERROR_STATUS 

ModuleName  ManagedPipelineHandler 

Notification 128 
HttpStatus  401 
HttpReason  Unauthorized 
HttpSubStatus 0 
ErrorCode  0 

ConfigExceptionInfo 

Notification EXECUTE_REQUEST_HANDLER 

ErrorCode  The operation completed successfully. (0x0) 

Questo messaggio a volte è gettato con ModuleName: ScriptModule

ho già sprecato 2 giorni su questa cosa e io sono a corto di idee in modo che qualsiasi suggerimento sarebbe apprezzato.

+9

cinque richieste dovrebbero essere sufficienti per chiunque. –

+2

La tua ragione per ipotizzare che non si tratta di un problema di codifica non sembra valida. –

+0

@Matt - non è affatto utile, ma potenziato per il divertimento. –

risposta

1

Ho risolto il problema alla fine. Ecco quello che ho fatto:

  1. sperimentato con le impostazioni di IIS e riciclaggio App_Pool e ho notato che non c'è niente di sbagliato nel modo in cui gestisce le richieste che in realtà raggiungerla.

  2. Mi sono concentrato sul modulo Http.sys e ho notato che nei file di registro c'erano molti errori Timer_ConnectionIdle e Client_Reset.

  3. Dopo alcuni esperimenti e molte ricerche su Google, ho trovato per errore questo answer e ho risolto il problema. Come suggerisce la risposta, il problema è stato causato dall'antivirus AVG installato e configurato in modo errato sul server.

Grazie per tutto l'aiuto e i suggerimenti.

0

Se si tratta di chiamate ajax che causano il blocco del browser, assicurarsi che non siano chiamate blocking ajax.

+0

La maggior parte delle chiamate Ajax viene eseguita da JQuery con gestori Http e la maggior parte sono asincroni e con un timeout di 500ms. – Constantin

+0

Vorrei provare ad aumentare il timeout a qualcosa come 15 secondi. Potrebbe essere il numero effettivo di connessioni che causano problemi. 500 ms potrebbero causare problemi di usabilità se un utente ha comunque una connessione internet lenta. – Matthew

+0

Inoltre, se stai utilizzando un server IIS locale su Windows 7 o Vista, penso che il numero massimo di connessioni consentite in una volta sia 10. – Matthew

4

Come qualsiasi grosso problema generico, la soluzione migliore per diagnosticare il problema è capire come suddividere il problema in parti più piccole, come ipotizzare i problemi e come convalidare o invalidare le ipotesi. La mia prima inclinazione sarebbe quella di ipotizzare che i processi lato server in questo particolare stiano impiegando molto tempo, causando il blocco delle richieste dei client, facendo sembrare tutto congelato.

Da lì, vorrei provare a replicare i processi lato server a lungo termine creando test lato client isolati - forse se gli URL sono HTTP, testerei gli stessi URL individualmente. Se fossero post HTTP, creerei un modulo di test isolato, se possibile, per vedere cosa succede con ciascuna richiesta. Se viene trovato un processo lato server a lunga esecuzione, hai un punto di partenza.

Se non ci sono processi lato server in esecuzione lunghi, potrebbero essere problemi di codifica lato JavaScript/client che devono essere esaminati. Ma sicuramente quando stai lavorando a un progetto ampio e sconosciuto, la soluzione migliore è capire come suddividere il problema in componenti più piccoli che possano essere testati

0

Basta accodare la risposta di Shan, che è buona.

Prima di tutto, c'è ovviamente un problema di codice in quanto questo non è affatto un comportamento "normale" per IIS.

Detto questo, è necessario isolarlo come indicato da Shan.Ad esempio, dato che il server stesso non accetta più connessioni, possiamo benissimo eliminare javascript come fonte del problema e relegarlo ad essere solo un sintomo.

In genere quando un processo di lavoro gira nello spazio come questo, è dovuto a un ciclo infinito oa un problema in cui più thread tentano di bloccare la stessa risorsa. Scommetto che se lo lasci eseguire abbastanza a lungo, IIS farà scadere, uccidere e riavviare il processo.

Con questo in mente si desidera cercare qualsiasi tipo di immondizia multithread (che consiglio vivamente di Non fare in un web server) o per qualsiasi cosa che indica un ciclo infinito stretto. Un ciclo diventerà evidente se si eseguono le richieste singolarmente. Un problema multi-threaded verrà visualizzato solo se si verifica una collisione.

Eseguire vari contatori delle prestazioni sul server Web. Inoltre, una volta bloccato, lasciarlo riposare per un po '. Una volta che IIS esegue il proprio reset sul processo di lavoro, cerca gli indicatori nel registro eventi.

Problemi correlati