C# SQL Server 连接字符串异步处理=true
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1642705/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
SQL Server connection string Asynchronous Processing=true
提问by George2
I am using .Net 2.0 + SQL Server 2005 Enterprise + VSTS 2008 + C# + ADO.Net to develop ASP.Net Web application.
我正在使用 .Net 2.0 + SQL Server 2005 Enterprise + VSTS 2008 + C# + ADO.Net 来开发 ASP.Net Web 应用程序。
My question is, if I am using Asynchronous Processing=truewith SQL Server authentication mode (not Windows authentication mode, i.e. using sa account and password in connection string in web.config), I am wondering whether Asynchronous Processing=truewill impact performance of my web application (or depends on my ADO.Net code implementation pattern/scenario)? And why?
我的问题是，如果我使用Asynchronous Processing=trueSQL Server 身份验证模式（不是 Windows 身份验证模式，即在 web.config 中的连接字符串中使用 sa 帐户和密码），我想知道是否Asynchronous Processing=true会影响我的 Web 应用程序的性能（或取决于我的ADO.Net 代码实现模式/场景）？为什么？
采纳答案by marc_s
Just having the Asynchronous Processing=Truein your connection string just simply enables you to write asynchronous queries - I don't see how having that setting in your connection string should affect your performance, if you don't change anything else.
仅Asynchronous Processing=True在您的连接字符串中包含 只是让您能够编写异步查询 - 如果您不更改任何其他内容，我看不出在您的连接字符串中设置该设置会如何影响您的性能。
You will hopefully begin to see a positive effect on your performance when you start doing asynchronous processing of your database queries. But just specifying that one option shouldn't have any (positive or negative) impact on your app.
当您开始对数据库查询进行异步处理时，您有望开始看到对性能的积极影响。但只需指定一个选项不应对您的应用产生任何（正面或负面）影响。
Marc
马克
回答by Cohen
Contradictory to what the accepted answer says, it actually has an impact on performance.
与接受的答案所说的相反，它实际上对性能有影响。
Atleast: according to the msdn documentation. In practice however I wasn't able to see any difference in a SQL 2005 Express scenario with .Net 3.5 SP1.
至少：根据msdn 文档。然而在实践中，我无法看到 SQL 2005 Express 场景与 .Net 3.5 SP1 的任何区别。
Since MSDN docs warns about this I thought it should be interesting for future reference.
由于 MSDN 文档对此发出警告，我认为它应该很有趣以供将来参考。
回答by ibirite
As a matter of fact, there are performance issues when you enable that option; see the ADO.NET 2.0 Asynchronous Command Execution (ASYNC) FAQ:
事实上，启用该选项时会出现性能问题；请参阅ADO.NET 2.0 异步命令执行 (ASYNC) 常见问题解答：
Q: What is the new ADO.NET 2.0 Asynchronous Command Execution feature.
A: ASYNC allows you to execute a command in a non-blocking manner. We are exposing in the SqlCommand the following asynchronous methods: BeginExecuteNonQuery, BeginExecuteReader and BeginExecuteXmlReader with polling, synchronization and (shudder) callbacks.Q: So does this mean that every command I execute (sync or async) will happen in overlapped mode when I add ASYNC=TRUE to the connection string?
A: Yes it does, everythingthat we execute on this connection will be done in overlapped mode. For synchronous operations we internally wait for the completion before returning, we are basically faking the synchronous behavior on this connection. This is the reason why we require a connection string keyword.Q: Does this have a perf impact?
A: Definitely, only use ASYNC=TRUE when you know that you are going to be using the async functionality.
问：什么是新的 ADO.NET 2.0 异步命令执行功能。
答：ASYNC 允许您以非阻塞方式执行命令。我们在 SqlCommand 中公开了以下异步方法：BeginExecuteNonQuery、BeginExecuteReader 和 BeginExecuteXmlReader，带有轮询、同步和（颤抖）回调。问：这是否意味着当我将 ASYNC=TRUE 添加到连接字符串时，我执行的每个命令（同步或异步）都会在重叠模式下发生？
A：是的，我们在此连接上执行的所有操作都将在重叠模式下完成。对于我们在内部等待完成后再返回的同步操作，我们基本上是在这个连接上伪造同步行为。这就是我们需要连接字符串关键字的原因。问：这对性能有影响吗？
答：当然，只有在您知道将要使用异步功能时才使用 ASYNC=TRUE。
回答by Shtin
I've just tested performance of syncdatabase calls with ASYNC=TRUE and ASYNC=FALSE. I was concerned about:
我刚刚用 ASYNC=TRUE 和 ASYNC=FALSE测试了同步数据库调用的性能。我担心的是：
A: Definitely, only use ASYNC=TRUE when you know that you are going to be using the async functionality
答：当然，只有在您知道将要使用异步功能时才使用 ASYNC=TRUE
I can say that the performance is exactly the same. I tested in Azure web role under high load and calculated average for big number of requests.
我可以说性能完全一样。我在高负载下在 Azure Web 角色中进行了测试，并计算了大量请求的平均值。
So if your application uses different types of database queries (sync and async) you can freely set Asynchronous Processing=trueand use this connection for both sync and async queries. It will also keep your connection pool smaller, I believe.
因此，如果您的应用程序使用不同类型的数据库查询（同步和异步），您可以自由地Asynchronous Processing=true为同步和异步查询设置和使用此连接。我相信，它还将使您的连接池变小。
回答by tugberk
Begining with .NET Framework 4.5, Asynchronous Processing property is ignored, thus it's unnecessary to include it.
从 .NET Framework 4.5 开始，异步处理属性被忽略，因此没有必要包含它。
Quote:
引用：
Prior to .NET Framework 4.5, asynchronous programming with SqlClient was done with the following methods and the Asynchronous Processing=true connection property:
- System.Data.SqlClient.SqlCommand.BeginExecuteNonQuery
- System.Data.SqlClient.SqlCommand.BeginExecuteReader
- System.Data.SqlClient.SqlCommand.BeginExecuteReader
This functionality remains in SqlClient in .NET Framework 4.5.
Beginning in the .NET Framework 4.5, these methods no longer require Asynchronous Processing=true in the connection string.
在 .NET Framework 4.5 之前，使用 SqlClient 进行异步编程是通过以下方法和 Asynchronous Processing=true 连接属性完成的：
- System.Data.SqlClient.SqlCommand.BeginExecuteNonQuery
- System.Data.SqlClient.SqlCommand.BeginExecuteReader
- System.Data.SqlClient.SqlCommand.BeginExecuteReader
此功能保留在 .NET Framework 4.5 中的 SqlClient 中。
从 .NET Framework 4.5 开始，这些方法不再需要连接字符串中的 Asynchronous Processing=true。
For more information, refer to below links:
有关更多信息，请参阅以下链接：
