Cadena de conexión del Servidor SQL Procesamiento asíncrono = verdadero

Estoy utilizando .Net 2.0 + SQL Server 2005 Enterprise + VSTS 2008 + C# + ADO.Net para desarrollar la aplicación web ASP.Net.Cadena de conexión del Servidor SQL Procesamiento asíncrono = verdadero

Mi pregunta es si estoy usando Asynchronous Processing=true con el modo de autenticación SQL Server (no el modo de autenticación de Windows, es decir, usando una cuenta sa y una contraseña en cadena de conexión en web.config), me pregunto si Asynchronous Processing=true afectará el rendimiento de mi web aplicación (o depende de mi patrón/escenario de implementación de código ADO.Net)? ¿Y por qué?

Fuente

2009-10-29 George2

Tener solo el Asynchronous Processing=True en su cadena de conexión simplemente le permite escribir consultas asíncronas: no veo cómo tener esa configuración en su cadena de conexión debería afectar su rendimiento, si no cambia nada más.

Es de esperar que comiences a ver un efecto positivo en tu rendimiento cuando comiences a hacer un procesamiento asíncrono de tus consultas a la base de datos. Pero solo especificando que una opción no debería tener ningún impacto (positivo o negativo) en su aplicación.

Marc

Fuente

2009-10-29 11:12:03

Gracias Marc! 1. ¿Significa esta opción, si habilito esta opción, entonces puedo usar API asíncrona desde ADO.Net, y si deshabilito esta opción, no puedo usar API asíncrona de ADO.Net? 2. Si no estoy usando API asíncrona de ADO.Net, no estoy seguro de si esta opción tiene algún impacto en mi código si no utilizo ninguna API asíncrona de ADO.Net. Tengo esta confusión porque no estoy seguro de si el código subyacente de ADO.Net usa procesamiento asíncrono para optimizar el rendimiento (por ejemplo, usar el elemento de trabajo de la cola del grupo de subprocesos), así que si establezco falso en esta opción, ¿se bloqueará la optimización del código subyacente? – George2

(continúa.) incluso si no uso API asincrónica del código ADO.Net explícitamente. ¿Algún comentario a mis dos puntos? – George2

por lo que yo entiendo, esta configuración solo ** le permite ** usar consultas async ADO.NET, pero no hace nada automáticamente. Y sí, si no ha especificado esta configuración, ** NO ** podrá usar consultas async ADO.NET. –

En contradicción con lo que dice la respuesta aceptada, lo que realmente tiene un impacto en el rendimiento.

Al menos: de acuerdo con msdn documentation. En la práctica, sin embargo, no pude ver ninguna diferencia en un escenario SQL 2005 Express con .Net 3.5 SP1.

Dado que los documentos de MSDN advierten sobre esto, pensé que debería ser interesante para referencia futura.

Fuente

2011-10-19 14:59:35 Cohen

De hecho, hay problemas de rendimiento cuando habilita esa opción; vea el ADO.NET 2.0 Asynchronous Command Execution (ASYNC) FAQ:

P: ¿Qué es la nueva característica ADO.NET 2.0 Asynchronous Command Execution.
A: ASYNC le permite ejecutar un comando de forma no bloqueante. Estamos exponiendo en el SqlCommand los siguientes métodos asincrónicos: BeginExecuteNonQuery, BeginExecuteReader y BeginExecuteXmlReader con sondeo, sincronización y (estremecimiento) devoluciones de llamada.

...

Q: ¿Quiere decir esto que todos los comandos que ejecutar (o sincronización asíncrona) va a pasar en modo solapado cuando agrego ASYNC = TRUE para la cadena de conexión?
A: Sí lo hace, Todo lo que ejecutamos en esta conexión se realizará en modo superpuesto. Para las operaciones sincrónicas esperamos internamente la finalización antes de regresar, básicamente estamos simulando el comportamiento síncrono en esta conexión. Esta es la razón por la cual requerimos una palabra clave de cadena de conexión.

P: ¿Esto tiene un impacto de perforación?
A: Definitivamente, solo use ASYNC = TRUE cuando sepa que va a utilizar la funcionalidad asincrónica.

...

Fuente

2011-10-21 16:46:58 ibirite

Aquí es una esencia que contiene una clase para ayudar a modificar las cadenas de conexión para garantizar que se establecen procesamiento asincrónico = True: el rendimiento https://gist.github.com/2597691

Fuente

2012-05-04 21:00:14

que he acabo de probar de sincronización llamadas a la base de datos con ASYNC = TRUE y ASYNC = FALSE. Estaba preocupada por:

R: Definitivamente, sólo utilizan ASYNC = TRUE cuando se sabe que se va a utilizar la funcionalidad asincrónica

puedo decir que el rendimiento es exactamente el mismo. Probé en la función web de Azure en alta carga y el promedio calculado para una gran cantidad de solicitudes.

Así que si su aplicación utiliza diferentes tipos de consultas de bases de datos (sincronización y asincronía) puede establecer libremente Asynchronous Processing=true y usar esta conexión para consultas sincronizadas y asincrónicas. También mantendrá su grupo de conexión más pequeño, creo.

Fuente

2013-05-06 19:55:54 Shtin

Gracias por hacer y compartir. Supongo que también te mostraste escéptico sobre la idea de que esto afecte el rendimiento, especialmente. dado que los puertos de terminación IO son una práctica estándar para IO en Windows, por una buena razón, y por qué es el valor predeterminado en 4.5, de lo contrario 'async-await' no tendría sentido. –

Comenzando con .NET Framework 4.5, se ignora la propiedad de Procesamiento asincrónico, por lo tanto, no es necesario incluirlo.

Cita:

Antes de .NET Framework 4.5, la programación asincrónica con SqlClient se realizó con los siguientes métodos y el procesamiento = true propiedad de conexión asíncrona :

System.Data. SqlClient.SqlCommand.BeginExecuteNonQuery

System.Data.SqlClient.SqlCommand.BeginExecuteReader

Sistema .Data.SqlClient.SqlCommand.BeginExecuteReader

Esta funcionalidad se mantiene en SqlClient en .NET Framework 4.5.

A partir de .NET Framework 4.5, estos métodos ya no requieren Procesamiento asíncrono = verdadero en la cadena de conexión.

Para obtener más información, consulte los enlaces siguientes:

Fuente

2013-06-16 09:35:57 tugberk

Cadena de conexión del Servidor SQL Procesamiento asíncrono = verdadero

Respuesta

Cuestiones relacionadas