Строка подключения SQL Server Асинхронная обработка = истина
Я использую .Net 2.0 + SQL Server 2005 Enterprise + VSTS 2008 + С# + ADO.Net для разработки веб-приложения ASP.Net.
Мой вопрос: если я использую Asynchronous Processing=true
с режимом проверки подлинности SQL Server (не в режиме проверки подлинности Windows, то есть с использованием учетной записи sa и пароля в строке подключения в web.config), мне интересно, повлияет ли Asynchronous Processing=true
на производительность моего веб-приложения (или зависит от моего кода/сценария реализации кода ADO.Net)? И почему?
Ответы
Ответ 1
Просто наличие Asynchronous Processing=True
в вашей строке подключения просто позволяет вам писать асинхронные запросы - я не вижу, как этот параметр в строке подключения влияет на вашу производительность, если вы ничего не измените.
Вы, надеюсь, начнете видеть положительное влияние на вашу производительность при запуске асинхронной обработки запросов к базе данных. Но просто указывая, что один из вариантов не должен иметь никакого (положительного или отрицательного) воздействия на ваше приложение.
Марк
Ответ 2
По сути, при включении этой опции возникают проблемы с производительностью; см. часто задаваемые вопросы ADO.NET 2.0 асинхронных команд (ASYNC):
В: Какова новая функция асинхронного выполнения ADO.NET 2.0.
A: ASYNC позволяет выполнять команду неблокирующим образом. Мы раскрываем в SqlCommand следующие асинхронные методы: BeginExecuteNonQuery, BeginExecuteReader и BeginExecuteXmlReader с опросами, синхронизацией и (содроганием) обратных вызовов.
...
Q: Значит ли это, что каждая команда, которую я выполняю (синхронизация или асинхронный), будет выполняться в режиме перекрытия, когда я добавляю ASYNC = TRUE в строку подключения?
A: Да, все, что мы выполняем в этом соединении, будет выполнено в режиме перекрытия. Для синхронных операций мы внутренне ожидаем завершения до возвращения, мы в основном подделываем синхронное поведение в этом соединении. Именно по этой причине нам требуется ключевое слово строки подключения.
В: Имеет ли это влияние? A: Определенно, используйте ASYNC = TRUE, когда вы знаете, что собираетесь использовать асинхронные функции.
...
Ответ 3
Начиная с .NET Framework 4.5, свойство асинхронной обработки игнорируется, поэтому его необязательно включать.
Цитата:
До .NET Framework 4.5 асинхронное программирование с помощью SqlClient было сделано со следующими методами: асинхронный Обработка = истинное свойство соединения:
- System.Data.SqlClient.SqlCommand.BeginExecuteNonQuery
- System.Data.SqlClient.SqlCommand.BeginExecuteReader
- System.Data.SqlClient.SqlCommand.BeginExecuteReader
Эта функция остается в SqlClient в .NET Framework 4.5.
Начиная с .NET Framework 4.5, эти методы больше не требуют Асинхронная обработка = true в строке подключения.
Для получения дополнительной информации см. ссылки ниже:
Ответ 4
Противоречащий тому, что говорит принятый ответ, на самом деле влияет на производительность.
По крайней мере: согласно msdn documentation.
На практике, однако, я не видел различий в сценарии SQL 2005 Express с .Net 3.5 SP1.
Поскольку MSDN docs предупреждает об этом, я думал, что это должно быть интересно для будущей справки.
Ответ 5
Я только что протестировал производительность вызовов синхронизации с ASYNC = TRUE и ASYNC = FALSE. Меня беспокоило:
A: Определенно, используйте ASYNC = TRUE, когда вы знаете, что собираетесь использовать асинхронную функциональность
Я могу сказать, что производительность точно такая же. Я тестировал веб-роль Azure при высокой нагрузке и рассчитывал среднее значение для большого количества запросов.
Итак, если ваше приложение использует разные типы запросов к базе данных (синхронизация и асинхронный), вы можете свободно установить Asynchronous Processing=true
и использовать это соединение для синхронных и асинхронных запросов. Я думаю, что это также уменьшит ваш пул соединений.
Ответ 6
Вот суть, которая содержит класс, который поможет изменить строки подключения, чтобы убедиться, что они устанавливают асинхронную обработку = True: https://gist.github.com/2597691