Determinazione di cosa sta facendo pressione su IIS

Question

Ho ottenuto un server dedicato con IIS 7.5 e SQL Server 2010. Il carico della CPU del server è spesso vicino al 100%. Il server SQL non richiede troppo, ma il processo w3wp sta prendendo una quantità significativa di CPU (spesso 70 +%).

mi piacerebbe sapere, che cosa sta causando questa pressione: * Troppe richieste di file statici (un CDN si potrebbe aggiungere) * Troppe richieste ajax (Sto pensando di cometa prese/web in ogni modo) * Le singole pagine asp.net consumano troppa potenza di elaborazione (dovrebbe essere facile da ottimizzare)

Dove inizieresti a cercare dove iniziare l'ottimizzazione?

Answer 1

Il modo più semplice possibile è profilare l'app in produzione. Non sono sicuro che sia possibile nel tuo caso. Alcune opzioni:

• esaminare i registri e osservare la durata delle richieste. È probabile che le lunghe richieste caricino il sistema
• Remote debug w3wp con Visual Studio e interrompi il debugger 10 volte per vedere dove si ferma maggiormente. Questo è il punto caldo
• Usa XPerf o PerfView per catturare pile (gestite). Ciò non ha praticamente alcun impatto sulle prestazioni di produzione

Answer 2

Probabilmente il modo più semplice per capirlo sarebbe installare New Relic sul server. Il processo dura 30 giorni, penso che quindi dovrebbe darti abbastanza tempo per arrivare a fondo. Ti mostrerà query SQL a esecuzione prolungata, metodi .NET e qualsiasi altra cosa tu possa pensare. Rende molto facile identificare i colli di bottiglia.

---

A proposito, ho suggerito New Relic perché sembra che il tuo problema sia in un ambiente di produzione. New Relic non è un profiler incredibilmente dettagliato. Raccoglie informazioni sufficienti per essere utile, ma non tanto da rallentare il server. Ciò lo rende adatto a questo scopo.

Se, tuttavia, è possibile riprodurre il problema in un ambiente di sviluppo, è possibile provare qualcosa come il Eqatec profiler gratuito.

Answer 3

Un buon punto di partenza sarebbe quello di accendere gli strumenti di sviluppo (F12 in IE/Chrome) e guardare i tempi sotto la scheda di rete. Questo ti mostrerà un diagramma a cascata per come la pagina è stata caricata e dovrebbe aiutarti a identificare i file statici a caricamento particolarmente lento che potrebbero essere sensibilmente trasferiti su un cdn, a fare richieste inutili, a quanto tempo viene speso la stessa pagina effettiva, ecc.

Successivamente, profili l'applicazione con un profiler delle prestazioni. Un buon profiler come ANTS Performance Profiler ti consente di esaminare elementi come il tempo di esecuzione/conteggi di hit per diversi metodi, nonché quali query del database vengono eseguite e per quanto tempo stanno prendendo. Una nuova versione di ANTS (attualmente in EAP) raggrupperà anche quell'attività in base alla richiesta http in modo da poter vedere se pagine specifiche necessitano di ottimizzazione o vengono colpite troppe volte.

Farebbe anche bene a verificare che la memorizzazione nella cache funzioni come previsto, in modo che gli utenti non richiedano ripetutamente la richiesta di pagine.

C'è anche un bell'articolo sulle prestazioni ASP.NET che potresti voler leggere su http://aspalliance.com/1533_ASPNET_Performance_Tips.7.

Disclaimer: Lavoro per Red Gate che produce ANTS.

Answer 4

Ho trovato un modo semplice per vedere cosa sta succedendo sul server. Tuttavia, il modo professionale è probabilmente quello di andare e utilizzare uno strumento di profilazione.

Cosa ho fatto? Nella console di IIS è possibile ottenere un elenco di tutti i thread di lavoro correnti e se si sceglie uno si può vedere su cosa sta lavorando questo thread. Così sono stato in grado di vedere che il thread gestiva 100 richieste in parallelo, 70 di quelle stavano risalendo alla stessa chiamata ajax.

La soluzione immediata era ridurre la frequenza di quella chiamata (da ogni 10 a ogni 30 secondi). Il prossimo passo sarà quello di ottimizzare ulteriormente la chiamata sul lato server dal momento che ho altre chiamate ajax con la stessa frequenza (ogni 10 secondi) che quasi mai si sono presentate nell'elenco delle richieste attive poiché erano così veloci.