Una sessione molto densa di tips&tricks nell'ottimizzare il codice di ado.net.
Si inizia con le stringhe di connessione. Con RegMon si nota che la i parametri vengono recuperati ad un notevole costo di tempo. Il consiglio è quello di specificare il più dettagliatamente possibile i parametri in modo che non sia necessario cercarli sul server.
E ancora è meglio usare "(local)" e non "." per collegarsi alla macchina locale. Infatti "." è usato per le named pipes mentre "(local)" per il tcp/ip.
Il connection pool in applicazioni multithreading è soggetto a una lista sincronizzata e quindi può soffrire dell'imbuto della sincronizzazione. Attenzione quindi a bilanciare l'uso di connection pooling con il numero di thread usati.
Quando si usa sql server, le richieste vengono accodate su una base per-connessione. Questo significa che se un comando impiega molto tempo, tutto ciò che viene eseguito con quella connessione, anche se in asincrono, dovrà aspettare.
Ado.net tenta di usare la sp_executesql se la query ha dei parametri. Questo, oltre ad evitare sql injection, aumenta le performance per il query plan reuse di sql server. Se non vengono usati i parametri, l'"auto parametrizzazione" cercherà di parametrizzare comunque la query, con tutti i problemi che potrebbero derivarne. Ancora una volta insisto a dire che bisogna usare i parametri, sempre.
Altra raccomandazioni sono quelle di usare le transazioni per esempio inserendo un grosso numero di record o di scorrere sempre tutto il resultset quando si usa un datareader e non di chiuderlo se ci sono ancora dei dati no fetched.
Se ancora fosse necessario, viene raccomandato di non usare il CommandBuilder e nessuno dei presenti alza la mano quando viene chiesto se qualcuno lo usasse.
Se molte di queste cose erano già note, credo che sia comunque importante ripeterle e dare i dettagli di performance che sono stati citati. Spero che slide ed esempi diventino pubblici per mostrare nero su bianco il valore di questi consigli.