Questa non è una domanda "che è l'ORM più veloce", né è una domanda su "come scrivere codice buono con ORM". Questo è l'altro lato: il codice è stato scritto, è andato in diretta, diverse migliaia di utenti stanno colpendo l'applicazione, ma c'è un problema di prestazioni generali percepito. Una traccia di SQL Profiler può essere eseguita solo per un breve periodo di tempo: 5 minuti danno diverse centinaia di migliaia di risultati.Tracciamento delle prestazioni ORM
La domanda è semplicemente questa: dopo aver utilizzato SQL Profiler per restringere un numero di query lente (durata superiore a un determinato periodo di tempo), quali tecniche e soluzioni esistono per tracciare nuovamente queste query SQL nel componente problematico? Una domanda relativa è che se un'area specifica è lenta, come possiamo identificare l'SQL che questa area sta eseguendo in modo che possa essere opportunamente filtrata in SQL Profiler?
Lo sfondo di questo è che abbiamo un'applicazione piuttosto grande con una struttura di tabella abbastanza complessa, ed è attualmente basata sull'accesso ai dati tramite stored procedure. Se si verifica un problema di prestazioni SQL, di solito è il caso di estrarre SQL Profiler, scoprire se c'è qualcosa di lento (filtro per durata) o se l'area lamentata è lenta (filtro per stored procedure) e ottimizzare le stored procedure (o lo schema - tramite indicizzazione).
Ora c'è una spinta per spostare il nostro codice da una soluzione principalmente sproc ad una soluzione ORM per lo più, tuttavia la grande spinta contro il movimento è come i problemi di prestazioni, se si presentano, possono essere ricondotti al codice problematico. Ho letto e sembra che il più delle volte, potrebbe coinvolgere strumenti di terze parti (utilità di traccia ORM come NHProf o .NET che tracciano utils come dottrace) che dovremmo installare sul server. Ora se gli strumenti aggiuntivi possono essere installati su un ambiente live è un'altra domanda, quindi se cose come questa possono essere eseguite senza strumenti aggiuntivi, allora quello potrebbe essere un bonus.
Sono principalmente interessato a soluzioni con SQL Server 2008, ma è probabilmente abbastanza generico per qualsiasi RDBMS. Per quanto riguarda la tecnologia ORM, su questo non ho un focus specifico in quanto nulla è attualmente in uso, quindi è interessante sapere come le tecniche differiscono (o sono comuni) in tweenHibernate, fluent-nhibernate e Entity Framework. Altri ORM sono benvenuti se offrono qualcos'altro :-)
Ho letto attraverso How to find and fix performance problems (...), e penso che il problema sia semplicemente la sezione lì che dice "isolare". Un problema facilmente riproducibile solo su un sistema live sarà difficile da isolare. Le cifre che ho citato nel paragrafo 2 sono figure dei tipi di volumi che possiamo ottenere da un profilo ...
Se si ha esperienza del mondo reale della tracciatura ORM dal vivo, tanto meglio :-)
Aggiornamento, 21-10-2016: Solo per completezza, alla fine abbiamo risolto questo problema con NHibernate scrivendo codice e sovrascrivendo i metodi di NHibernate. Dettagli completi in questa altra domanda SO ho chiesto: NHibernate and Interceptors - measuring SQL round trip times. Mi aspetto che questo sarà un approccio simile per molti ORM diversi.
Hai già familiarità con i vari DMV e rapporti che mostrano le query principali per durata, CPU, IO ecc. In base alle statistiche del piano di esecuzione piuttosto che alla profilazione? Anche quale versione di SQL Server? Se nel 2008 esiste il data warehouse di gestione che può essere di aiuto (anche se suppongo che con query non parametrizzate emesse da un ORM si possano finire con molte query e piani simili che rendono difficile aggregare i risultati) –
Interessante domanda, non vedo l'ora di imparare qualcosa su questo argomento poiché non ho una risposta per te. – HLGEM
@Martin - sorry, 2008 (domanda modificata). Ora menzioni i DMV, che suonano le campane, indagheranno. L'app al momento si basa su SQL 2000, ma la versione successiva è stata portata al 2008. Non * troppo * preoccupato per le soluzioni 2000. Sebbene una volta che abbiamo la query, come possiamo risalire al modulo che sta causando il problema tramite il livello ORM? –