Buon modo per cronometrare le query SQL quando si utilizza Linq to SQL

Question

Esiste un buon modo per cronometrare le query SQL quando si utilizza Linq to SQL?Mi piace molto la funzionalità di registrazione, ma sarebbe fantastico se potessi in qualche modo anche cronometrare quella query.Qualche idea?

Answer 1

SQL Profiler per ottenere la query e l'ora e anche il percorso di esecuzione nell'analizzatore di query per vedere dove sono i colli di bottiglia.

Answer 2

Come già detto da due persone, SQL Profiler è lo strumento pronto all'uso da utilizzare a questo scopo.Non voglio fare l'eco ma volevo approfondire un po':Non solo fornisce i tempi effettivi da SQL Server (al contrario dei tempi dal lato app in cui i/o di rete, connessione e tempi del pool di connessioni vengono aggiunti alla torta), ma fornisce anche il [spesso più importante] I /O dati statistici, informazioni di blocco (se necessario) ecc.

Il motivo per cui le statistiche di I/O sono importanti è che una query molto costosa può essere eseguita velocemente consumando quantità eccessive di risorse del server.Se, ad esempio, una query eseguita spesso colpisce tabelle di grandi dimensioni e non sono presenti indici corrispondenti risultanti dalle scansioni delle tabelle, le tabelle interessate verranno memorizzate nella cache da SQL Server (se possibile).Ciò a volte può far sì che la stessa query venga eseguita in modo incredibilmente veloce mentre in effetti sta danneggiando il resto del sistema/app/db consumando le risorse del server.

Le informazioni sul blocco sono quasi altrettanto importanti -> piccole query che eseguono ricerche PK per un singolo record possono avere tempi errati a causa del blocco e del blocco.Ho letto da qualche parte che proprio questo sito era afflitto da blocchi nei suoi primi giorni di beta.SQL Profiler è tuo amico anche per identificare e risolvere i problemi causati dal blocco.

Per riassumerlo;sia che utilizzi L2S, EF, semplice ADO, se vuoi assicurarti che la tua app "si comporti bene" nei confronti del database, tieni sempre SQL Profiler pronto durante lo sviluppo e il test.Si ripaga!

Modificare: Da quando ho scritto la risposta sopra ho sviluppato un nuovo strumento di profilazione del runtime per L2S che riunisce il meglio di entrambi i mondi;Statistiche di I/O e tempistiche lato server da SQL Server, piano di esecuzione di SQL Server, avvisi di "indice mancante" di SQL Server, combinati con lo stack di chiamate gestito per facilitare l'individuazione del codice che ha generato una determinata query e alcune opzioni di filtro avanzate per registrare solo le query che soddisfano determinati criteri.Inoltre, il componente di registrazione può essere distribuito con le app per semplificare la profilazione delle query di runtime negli ambienti dei clienti in tempo reale.Lo strumento può essere scaricato da:

http://www.huagati.com/L2SProfiler/ dove puoi anche ottenere una licenza di prova gratuita di 45 giorni.

Una descrizione di base più lunga e un'introduzione allo strumento sono pubblicate anche qui:
http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html

...e un esempio/procedura dettagliata sull'utilizzo di alcune delle opzioni di filtro più avanzate è disponibile qui:
http://huagati.blogspot.com/2009/08/walkthrough-of-newest-filters-and.html

Answer 3

Potresti usare a System.Diagnostics.Stopwatch ti consentirà di tenere traccia del tempo di esecuzione della query.Ricorda solo che le query Linq->SQL non vengono eseguite finché non le enumeri.Tieni inoltre presente che se stai accedendo a Console.Out ci sarà un calo significativo delle prestazioni.

Answer 4

Quello che potresti fare è aggiungere un'implementazione TextWriter personalizzata a DataContext.Log che scriverà l'SQL generato in un file o in memoria.Quindi esegui il ciclo di tali query, eseguendole con codice ADO.NET non elaborato, circondandole ciascuna con un cronometro.

Ho già utilizzato una tecnica simile in precedenza perché sembrava che ogni volta che stavo sviluppando del codice non avessi mai aperto Profiler ed era davvero facile generare tali risultati in una pagina HTML.Sicuramente li eseguirai due volte per richiesta del sito web, ma è utile vedere i tempi di esecuzione al più presto invece di aspettare finché non trovi qualcosa in Profiler.

Inoltre, se stai seguendo il percorso dello strumento SQL, ti consiglio di cercare su Google "DMV della query più lenta" e di ottenere una procedura memorizzata che possa fornirti statistiche sulle query più lente nel tuo db.Non è sempre facile scorrere i risultati del profiler per trovare le query errate.Inoltre, con le query giuste su dmv di SQL 2005 puoi anche eseguire l'ordine per dire CPU vs.tempo e così via.

Answer 5

Utilizziamo SQL Profiler per testare le nostre query con LLBLGen Pro.

Answer 6

La soluzione migliore è registrare le query in un file e utilizzare SQL Profiler per cronometrarle e modificare gli indici per le query.