ASP.NET Асинхронные методы Вопрос

Question

Недавно один из разработчиков сказал мне, что вы ВСЕГДА должны выполнять вызовы базы данных асинхронно. (Либо используя ThreadPool.QueueUserWorkItem или IAsyncResult и делегаты)

Его оправдание было таким: IIS имеет только 24 (или около того) потока, которые он может использовать для запросов. Когда пользователь делает запрос, он получает один из этих потоков. Однако, когда вы используете асинхронные методы, вы получаете доступ к потокам Windows вне области IIS. Он сказал, что когда вы используете асинхронные методы таким образом, вы освобождаете исходный поток для запросов других пользователей и переносите его в поток Windows (на время жизни этого потока).

Что ты думаешь? Должны ли все вызовы БД быть асинхронными?

Answer 1

Количество рабочих потоков ограничено. Это связано с ASP.NET, а не с IIS (за исключением IIS7, где они одинаковы). Это правда, что вызовы базы данных или любой другой вызов использует один из этих потоков. В случае вызовов ADO.NET возможно записать ваши страницы в виде асинхронных страниц, где поток не используется во время выполнения операции базы данных.

Вам не следует беспокоиться об этом до тех пор, пока у вас не возникнет проблема.

Answer 2

Есть ли у вас основания полагать, что вы попадете в такое узкое место? Этот стиль программирования сложен, у вас должна быть серьезная причина, чтобы принять такой подход.

Ограничение по умолчанию составляет 20 рабочих потоков, но помните, что это ограничение на ядро ​​ЦП. Если этот лимит стал проблемой в том, что ASP.NET стал бездействующим, ожидая завершения запросов к БД, почему бы просто не немного увеличить лимит потока (на самом деле я не предлагаю вам сделать это, поскольку на самом деле не думаю, что это будет необходимо ).

Answer 3

Если ваш сайт настолько успешен, что у вас не хватает потоков для запросов на обслуживание, было бы дешевле, проще и менее подвержено ошибкам купить другой веб-сервер.

Вы могли бы напомнить этому разработчику, что переключение потоков не является бесплатной операцией, и в некоторые экземпляры могут занять больше времени, чем вызов db.