No estoy de acuerdo con Ricka en esto. Los comandos de base de datos asíncrona no solo son buenos, sino que son fundamentales para lograr escala, rendimiento y latencia. Su objeción sobre el tiempo de aceleración del grupo de subprocesos se aplica solo a un servidor web que experimenta bajos volúmenes de tráfico.
En una situación de mucho tráfico (que es la única que importa), el grupo de subprocesos no tendrá que esperar para 'inyectar' nuevos subprocesos. Ejecutar los comandos SQL de forma asíncrona es importante no solo desde el punto de vista de las solicitudes del servidor web/salud de los subprocesos, sino también desde el punto de vista de la duración/latencia total de la solicitud:las llamadas a la base de datos no correlacionadas se pueden realizar en paralelo, a diferencia de secuencialmente. Esto por sí solo suele dar como resultado mejoras drásticas en la latencia de la solicitud HTTP tal como la experimenta el usuario. En otras palabras, sus páginas se cargan más rápido.
Sin embargo, un consejo:el comando SQL no es verdaderamente asíncrono hasta que habilite Asynchronous Processing=true
en la cadena de conexión. Si bien esto no está configurado (y de forma predeterminada no lo está, Editar:a partir de .NET Framework <4.5. Asynchronous Processing ya no es necesario
) sus llamadas 'asincrónicas' a BeginExecuteReader
no son más que una farsa, la llamada iniciará un hilo y bloqueará eso hilo. Cuando el verdadero procesamiento asíncrono está habilitado en la cadena de conexión entonces la llamada es verdaderamente asíncrona y la devolución de llamada se basa en la finalización de IO.
Una palabra de precaución:un comando SQL asíncrono se completa tan pronto como el primero El resultado regresa al cliente y los mensajes de información cuentan como resultado.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Has perdido todos los beneficios de async. La print crea un resultado que se envía de vuelta al cliente, que completa el comando asíncrono y la ejecución en el cliente se reanuda y continúa con 'reader.Read()'. Ahora eso se bloqueará hasta que la consulta compleja comience a producir resultados. Preguntas 'quién pone print en el procedimiento?' pero el print puede estar disfrazado de otra cosa, tal vez algo tan inocente como un INSERT que se ejecuta sin emitiendo primero un SET NOCOUNT ON
.
