Асинхронная обработка в SQL Server по сравнению с.NET Асинхронная обработка
Тайм-ауты соединения (принимающий локальную сеть и несколько клиентских машин) обычно следуют
a) некоторый брандмауэр на пути, который просто ест пакеты, не говоря вещи отправителя как "Никакой Маршрут разместить"
b) потеря пакетов из-за неправильной конфигурации сети или перегрузки строки
c) слишком много запросов, перегружающих сервер
d) небольшое количество одновременно доступных потоков/процессов на сервере, который приводит ко всем ним взятым. Это происходит особенно с запросами, которые занимают много времени для выполнения и могут объединиться с c).
Hope это помогает.
5 ответов
The problem with .NET asynchronous processing (BeginInvoke(...)) is that all this is doing is spinning off a thread to process the code synchronously. A 5 minute query will tie up a thread for 5 minutes, blocking (i.e. doing nothing for ~99% of the time) while a result is calculated at the remote end. Under strain (many queries at once) this will exhaust the threadpool, tying up all threads in a blocked state. The threadpool will become unresponsive and new work requests will suffer big latency waiting for the threadpool to fire up extra threads. This is not the intended use of the threadpool, as it is designed with the expectation that the tasks it is asked to complete are to be short-lived and non-blocking.
With Begin/EndAction APM pairs, one can invoke the same action in a non-blocking way, and it is only when the result is returned via an IO completion port that it is queued as a work item in the threadpool. None of your threads are tied up in the interim, and at the point that the queued response is dealt with, data is available meaning user code does not block on IO, and can be completed quickly... a much more efficient use of the threadpool which scales to many more client requests without the cost of a thread per outstanding operation.
Как упоминалось в предыдущих ответах, BeginInvoke использует поток .NET. Не менее важно то, что поток поступает из пула потоков ASP.NET, поэтому он конкурирует с клиентами за очень ограниченные ресурсы потока. То же самое верно и для ThreadPool.QueueUserWorkItem () .
Для асинхронных вызовов SqlClient требуется SqlConnection с включенным async = true. Этот режим требует немного больше сетевых накладных расходов (поэтому он не включен по умолчанию), но он не использует поток из пула потоков .NET. Вместо этого он использует асинхронный ввод-вывод.
Преимущество последнего подхода в том, что он гораздо более масштабируемый. Таким образом вы можете обрабатывать сотни или тысячи одновременных запросов, при этом накладные расходы на поток на вызов будут чрезвычайно высокими. Плюс,
.Net BeginInvoke просто откладывает выполнение в другом потоке. Это всегда будет медленнее, чем синхронный вызов, и потреблять дополнительные ресурсы. Единственная причина, по которой это будет использоваться, - это освободить контекст вызывающего абонента для перехода к другим операциям (например, возвратить результат HTTP-запроса клиенту).
Асинхронные методы SqlClient, когда AsynchronousProcessing для соединения установлено значение true, и используются методы BeginExecute для SqlCommand, которые являются действительно асинхронными. Команда SQL отправляется в сетевой канал связи, и завершение вызывается, когда результат возвращается сервером.
Хотя с точки зрения надежности ни один из этих методов бесполезен. Они оба полагаются на клиентский процесс, чтобы оставаться на связи, пока звонок не будет завершен. в противном случае SQL Server увидит отключение клиента и откажется от обработки, откатывая любую промежуточную работу. Рассмотрим приложение ASP, которое приняло HTTP-запрос, отправило «асинхронную» обработку платежа и вернуло ответ. Нет никакого способа гарантировать, что представленные работы действительно будут выполнены.
В ситуациях, когда обработка требует гарантий надежности, решение состоит в том, чтобы поставить работу в очередь на сервере, зафиксировать ее и затем продолжить, полагаясь на собственные возможности асинхронной обработки SQL Server. Это метод, который гарантирует обработку даже при отключении клиентов, перезапуске процесса ASP, отказоустойчивом зеркалировании или кластеризации SQL Server, аварийном восстановлении оборудования и многом другом, поскольку это надежный с точки зрения транзакций способ отправки запросов на асинхронную обработку. Для примера см. Асинхронное выполнение процедуры .
From this article SQL Server 2008 Books Online (October 2009) - Performing Asynchronous Operations, I quote:
Asynchronous processing enables methods to return immediately without blocking on the calling thread. This allows much of the power and flexibility of multithreading, without requiring the developer to explicitly create threads or handle synchronization.
If you have explicitly created those threads and handled the synchronization, perhaps you probably will not find much difference.
If you mean "Why use a data providers BeginExecute___()/EndExecute____() methods vs just wrapping a normal Execute____() in a delegate, I suspect the answer is that when they were first designing the provider model for ado.net for .Net 1.0, wrapping something in a delegate and invoking it asynchronously wasn't so simple.
Other possible reasons are that this matched how the old code they were updated or wrapping for the original .Net worked or that the built-in methods allow you to easily check any returned exceptions