#asp.net #async-await #asp.net-identity
#asp.net #async-await #asp.net-identity
Вопрос:
Рассмотрим этот простой псевдокод
User logs in
Application access database to try retrieve the login using provided password and username
if record is found then show requested page otherwise display login with error message
В чем преимущество асинхронности? Конечно, приложение не сможет продолжить работу, пока база данных не выполнит поиск записи.
Ответ №1:
Это более общий вопрос о async-await . Методы, выполняемые таким образом, не блокируют выполняющийся поток, и приложение доступно для выполнения другой работы, в то время как DB возвращается с результатом. Это означает, что ваше приложение может обслуживать другой запрос (возможно, от другого пользователя), ожидая, пока DB вернет результат.
Об этом много написано async-await . Вы можете начать отсюда: http://blogs.msdn.com/b/cdndevs/archive/2013/12/18/c-async-and-await-why-do-we-need-them-part-1.aspx
И, К вашему сведению, в библиотеке Identity есть неасинхронные методы, предоставляемые в качестве методов расширения. Поэтому, если ваше приложение не является асинхронным, вам не нужно использовать async ключевые слова на всем протяжении вашего приложения.
Ответ №2:
Вы правы в том, что ответ не может быть возвращен отправителю запроса до тех пор, пока база данных не выполнит поиск записи и не найдет результат, и запрос не завершит обработку.
Однако, сделав доступ к данным асинхронным, это позволит освободить поток запроса и вернуть его в пул потоков для обслуживания других запросов, а когда операция с данными позже завершится, поток запроса может быть взят из пула потоков и продолжен с остальной частью запроса.
Таким образом, поток запроса не блокируется от выполнения другой полезной работы во время ожидания операции с БД, как это было бы, если бы метод был синхронным.
Комментарии:
1. Для ясности, имеет ли смысл тогда говорить, что в приведенном выше примере фактический «процесс» поиска в базе данных и последующая часть отображения (в контексте приложения web / asp.net) по-прежнему «синхронны» (это собственный «поток»)? Я (думаю) понимаю это — особенно при запуске чего-то вроде консольного приложения, где «другие процессы» не заблокированы (например, обновления консоли) .. но концептуально борются в ASP.Net. Спасибо..
2. Не совсем. Аналогично аналогии с вашим консольным приложением, другие запросы (от других клиентов или того же клиента) не блокируются в ожидании, пока поток запросов освободится и начнет обработку.
3. Итак, как он «узнает» / «отслеживает», к какому потоку (UI / HTTP) «вернуться» (после получения результата db)? От Hanselman :
Async events in web applications are inherently strange beasts. Async void is meant for a fire and forget programming model. This works in Windows UI applications since the application sticks around until the OS kills it..there is guaranteed to be a UI thread that it can interact with. In web applications, this model falls apart since requests are by definition transient.4. Комментарий @EdSF Брэда Уилсона к этому сообщению в блоге является хорошим описанием для
async/awaitв ASP.NET5. Ага. Увидел это, и я вроде как в режиме «Uwe» в этом потоке 🙂 Это имеет смысл, поскольку образец выполняет несколько задач (io / network), необходимых для обслуживания запроса. Если бы я применил это к вышеупомянутой (предполагаемой одиночной) задаче получения чего-либо из db, это было бы # 2 в комментарии Брэда. Производительность повышается на сервере (для обработки запросов других пользователей ), но не обязательно для пользователя, делающего исходный запрос (выше, пользователь, вызывающий процесс login / db). Спасибо за ваше время!
Ответ №3:
Не знаю о рассматриваемом API, но вы можете ожидать асинхронные методы. Во время ожидания «другой код» продолжает выполняться. После того, как асинхронный метод выполнит то, что он когда-либо делал, выполнение возобновится с точки, в которой вы его ожидали. Если вы не ожидаете, это действует как синхронный метод.