Ответ 1
Чтобы решить, следует ли асинхронно или синхронизировать, сравните преимущества и затраты:
Асинхронный:
- Почти никогда не исчерпывайте пул потоков с помощью async (обстоятельства должны быть экстремальными)
- Довольно много произвольных уровней concurrency (одновременные запросы и операции)
- Сохраняет 1 МБ памяти на каждый сохраненный поток
- Безопасный внутрипроцесс concurrency благодаря
SynchronizationContext - Может увеличивать пропускную способность за счет низких двузначных процентных значений для случаев высокой нагрузки из-за снижения затрат на планирование ОС. Тем не менее, практически ни одно производственное приложение не находится под высокой загрузкой процессора, потому что, если оно было близко к недоступности (в случае всплеска нагрузки приложение начинает отбрасывать запросы).
Синхронизировать
- Простой код: ожидание делает 99% случаев (почти) так же просто, как и синхронный код. Тем не менее, 10+ асинхронных вопросов каждый день в Qaru говорят на другом языке. Крайние случаи возникают, когда вы отклоняетесь от простого пути. Также при использовании устаревших библиотек, которые, например, требуют от вас синхронного обратного вызова.
- Меньшая работа для кодирования и отладки
- Профилирование (вы можете профилировать приложение или просто приостановить отладчик и посмотреть, что делает приложение прямо сейчас. Невозможно с помощью async.)
- Взаимодействует с устаревшим кодом и библиотеками
Выберите async с ASP.NET, если вы вызываете службы с высокой задержкой. Веб-служба, вероятно, будет высокой задержкой. База данных OLTP почти всегда имеет низкую задержку.
Выберите async, если ваше приложение пользуется очень высокими уровнями concurrency (100 +). Большинство приложений не имеют таких высоких уровней, или их внутренние службы не будут поддерживать такую сумму нагрузки. Нет смысла делать масштаб веб-приложения, но перегружать его. Все системы в цепочке вызовов должны извлекать выгоду из высокой степени concurrency, чтобы асинхронность была полезной.
Типичные службы с высокой задержкой (хорошие случаи для async):
- Веб-сервисы
- Ожидание (например, сон)
- Дросселирование (
SemaphoreSlim,...) - Некоторые облачные сервисы (Azure)
- Долгосрочные запросы к базе данных (например, отчет или ETL)
Типичные службы с низкой задержкой (хорошие случаи для синхронизации):
- Вызов базы данных: большинство запросов OLTP имеют низкую задержку, потому что вы можете предположить, что сервер базы данных не будет перегружен. Нет смысла бросать на него 100 одновременных запросов. Не делает их более быстрыми.
- Файловая система: то же, что и базы данных.
Они классифицируются по типичному случаю. Все они могут быть и в противоположной категории.
Вы можете смешивать синхронизацию и асинхронное соединение в одном и том же приложении. Использовать async, когда он находится в его сладком месте.
Итак, почему Microsoft и команда Entity Framework поддерживают асинхронное использование? Здесь идет субъективная часть этого ответа: это может быть моя внутренняя политика Microsoft. Они могут предвидеть использование EF в клиентских приложениях (для которых async отлично). Или они не понимают, что асинхронные вызовы баз данных почти всегда являются пустой тратой времени разработчиков без преимуществ. Большинство людей этого не понимают, потому что асинк - это путь в эти дни.