ASP.NET async/wait, часть 2

У меня есть вариант преимуществ async/await-on-ASP.NET из этот вопрос.

Насколько я понимаю, асинхронность — это не то же самое, что параллелизм. Итак, на веб-сервере мне интересно, сколько преимуществ async/await приносит страницам ASP.NET.

Разве IIS+ASP.NET уже не очень хорошо распределяет потоки для запросов, и если одна страница занята ожиданием ресурса, сервер просто переключится на обработку другого запроса, у которого есть работа?

Существует ограниченное количество потоков в пуле для использования ASP.NET — использует ли асинхронность их более эффективно?

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

Я предполагаю, что это сводится к следующему:

Есть ли какое-либо преимущество в асинхронном чтении ресурса (скажем, файла или запроса БД) на странице ASP.NET по сравнению с блокировкой на ней?


async-await asp.net
person n8wrl    schedule 02.08.2012    source источник
comment
Вы действительно читали ответ Джона Скита, о котором вы упомянули? Он объясняет преимущества использования async в ASP.NET.   -  person svick    schedule 02.08.2012
comment
@svick: Спасибо, что прочитали. Да, я читал ответ Джона, но во многих случаях он говорит, что это зависит, и я думаю, что это ЕДИНСТВЕННЫЙ ответ, который он может дать. Я хотел бы понять последствия async/await для потоковой передачи на веб-сервере с большим объемом.   -  person n8wrl    schedule 02.08.2012

Ответы (1)


arrow_upward
8
arrow_downward

если одна страница занята ожиданием ресурса, сервер просто переключится на обработку другого запроса, у которого есть работа?

Я так не думаю. Я был бы очень удивлен, если бы это было так. Теоретически это возможно, но очень сложно.

Существует ограниченное количество потоков в пуле для использования ASP.NET — использует ли асинхронность их более эффективно?

Да, потому что, когда вы await что-то делаете, поток для этого запроса немедленно возвращается в пул.

Мы уже многопоточные, и веб-ответ не может быть завершен, пока не будут выполнены все задачи запроса, асинхронные или нет, верно?

Это правильно. async в серверном сценарии — это устранение нагрузки на пул потоков.

Есть ли какое-либо преимущество в асинхронном чтении ресурса (скажем, файла или запроса БД) на странице ASP.NET по сравнению с блокировкой на ней?

Абсолютно!

Если вы блокируете вызов файла/службы/запрос БД, то этот поток используется на время этой операции. Если вы await вызываете файл/службу/запрос БД, то этот поток немедленно возвращается в пул потоков.

Одним (действительно классным!) результатом этого является то, что у вас может быть запрос в процессе, и пока он (а) ожидает какой-либо операции, нет никаких потоков, обслуживающих этот запрос! Параллелизм с нулевым потоком, если хотите.

Когда операция завершается, метод возобновляется после await - в (возможно, другом) потоке из пула потоков.

В заключение: async масштабируется лучше, чем потоки, поэтому на стороне сервера определенно есть преимущество.

Дополнительная информация: мое собственное вступление к async сообщению и это потрясающее видео.

person Stephen Cleary    schedule 02.08.2012
comment
Обратите внимание на этот более свежий ответ: если вы говорите об ASP.NET MVC с одной базой данных, тогда вы (почти наверняка) не получите никаких преимуществ масштабируемости от async. Это связано с тем, что IIS может обрабатывать гораздо больше одновременных запросов, чем один экземпляр SQL-сервера (или другой классической СУБД). Однако, если ваша серверная часть более современная — кластер SQL-серверов, Azure SQL, NoSQL и т. д. — и ваша серверная часть может масштабироваться, а вашим узким местом в масштабируемости является IIS, тогда вы можете получить преимущество масштабируемости за счет async . - person DavidRR; 17.05.2017