Non sono d'accordo con Ricka su questo. I comandi Async DB non sono solo buoni, ma sono fondamentali per ottenere scalabilità, velocità effettiva e latenza. La sua obiezione sul tempo di accelerazione del pool di thread si applica solo a un server Web con bassi volumi di traffico.
In una situazione di traffico elevato (che è l'unica che conta), il pool di thread non dovrà attendere l'"iniezione" di nuovi thread. L'esecuzione dei comandi SQL in modo asincrono è importante non solo dal punto di vista dell'integrità delle richieste/thread del server Web, ma anche dal punto di vista della durata/latenza totale delle richieste:le chiamate DB non correlate possono essere eseguite in parallelo, anziché in sequenza. Questo da solo si traduce in genere in notevoli miglioramenti nella latenza della richiesta HTTP come sperimentato dall'utente. In altre parole, le tue pagine si caricano più velocemente.
Un consiglio però:SQL Command non è veramente asincrono finché non abiliti Asynchronous Processing=true
sulla stringa di connessione. Anche se non è impostato (e per impostazione predefinita non lo è, Modifica:a partire da .NET Framework <4.5. Asynchronous Processing non è più richiesto
) le tue chiamate "asincrone" a BeginExecuteReader
non sono altro che una farsa, la chiamata avvierà un thread e bloccherà quello filo. Quando la vera elaborazione asincrona è abilitata nella stringa di connessione quindi la chiamata è veramente asincrona e la richiamata si basa sul completamento dell'IO.
Un avvertimento:un comando SQL asincrono viene completato non appena il primo il risultato viene restituito al client e i messaggi informativi contano come risultato.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Hai perso tutti i vantaggi dell'asincrono. La print crea un risultato che viene inviato al client, che completa il comando asincrono e l'esecuzione sul client riprende e continua con 'reader.Read()'. Ora quello si bloccherà fino a quando la query complessa non inizierà a produrre risultati. Chiedi a 'chi mette print nella procedura?' ma la print può essere mascherato da qualcos'altro, forse qualcosa di innocente come un INSERT che viene eseguito senza prima emissione di un SET NOCOUNT ON
.
