Profilazione di SQL Server e / o ASP.NET

Question

Come si potrebbe fare per profilare alcune query che vengono eseguite da un'applicazione ASP.NET? C'è un software in cui lavoro che funziona in modo estremamente lento a causa del database (credo). Le tabelle hanno indici ma si trascina ancora perché funziona con così tanti dati. Come posso creare un profilo per vedere dove posso apportare alcuni piccoli miglioramenti che si spera possano portare a maggiori miglioramenti della velocità?

Modifica: vorrei aggiungere che al server web piace il timeout durante queste lunghe query.

Answer 1

Sql Server ha alcuni strumenti eccellenti per aiutarti in questa situazione. Questi strumenti sono integrati in Management Studio (che un tempo si chiamava Enterprise Manager + Query Analyzer).

Utilizza SQL Profiler per mostrare le query effettive provenienti dall'applicazione Web.

Copia ciascuna delle domande del problema (quelle che consumano molto tempo CPU o IO). Esegui le query con " Visualizza piano di esecuzione effettivo " ;. Spero che vedrai qualche indice ovvio che manca.

Puoi anche eseguire la procedura guidata di ottimizzazione (il pulsante si trova accanto a " mostra il piano di esecuzione effettivo " ;. Eseguirà la query e fornirà suggerimenti.

Di solito, se hai già indici e le query funzionano ancora lentamente, dovrai riscrivere le query in modo diverso.

Mantenere tutte le tue domande nelle procedure memorizzate rende questo lavoro molto più semplice.

Answer 2

Per profilare SQL Server, utilizzare SQL Profiler .

E puoi usare ANTS Profiler da Red Gate al profilo il tuo codice.

Answer 3

Un altro profiler .NET che funziona bene con ASP.NET è dotTrace . L'ho usato personalmente e ho trovato molti colli di bottiglia nel mio codice.

Answer 4

Credo che tu abbia la risposta di cui hai bisogno per profilare le query. Tuttavia, questa è la parte più semplice dell'ottimizzazione delle prestazioni. Una volta che sai che sono le query e non la rete o l'app, come trovi e risolvi il problema?

L'ottimizzazione delle prestazioni è una cosa complessa. Ma ci sono alcuni posti in cui guardare prima. Dici che stai restituendo molti dati? Stai restituendo più dati del necessario? Stai davvero restituendo solo le colonne e i record di cui hai bisogno? Restituire 100 colonne usando select * può essere molto più lento che restituire le 5 colonne che si stanno effettivamente utilizzando.

Gli indici e le statistiche sono aggiornati? Cerca come aggiornare statisistcs e reindicizzare in BOL se non lo fai da un po 'di tempo. Hai indici su tutti i campi di join? Che ne dici dei campi nella clausola where.

Hai usato un cursore? Hai usato subquery? Che ne dici di union-se lo stai usando può essere cambiato in union all?

Le tue query sono esagerate (google se non hai familiarità con il termine.)

Stai usando distinti quando potresti usare group by?

Stai ricevendo blocchi?

Ci sono molte altre cose da guardare, questi sono solo un punto di partenza.

Answer 5

Se c'è una particolare query o procedura memorizzata che voglio sintonizzare, ho trovato molto utile attivare le statistiche prima della query:

SET STATISTICS TIME ON
SET STATISTICS IO ON

Quando si attivano le statistiche in Query Analyzer, le statistiche vengono visualizzate nella scheda Messaggi del riquadro Risultati.

Le statistiche IO sono state particolarmente utili per me, perché mi fanno sapere se potrei aver bisogno di un indice. Se vedo un numero elevato di letture dalle statistiche IO, potrei provare ad aggiungere indici diversi alle tabelle interessate. Mentre provo un indice, eseguo nuovamente la query per vedere se il conteggio delle letture è diminuito. Dopo alcune iterazioni, di solito riesco a trovare i migliori indici per le tabelle interessate.

Ecco i collegamenti a MSDN per questi comandi statistici:

IMPOSTA TEMPO STATISTICO

SET STATISTICS IO