Должен ли я всегда использовать async / await в ASP. NET Core API Controller - PullRequest
Новая
       29

Должен ли я всегда использовать async / await в ASP. NET Core API Controller

1 голос
/ 11 апреля 2020

В качестве примера у меня есть ASP.NET Core API controller выборка некоторых данных из службы и 2 возможные способы реализации метода контроллера:

С помощью async / await: 

[HttpGet]
public async Task<IActionResult> GetSomeDataAsync()
{
   return await someService.GetSomeDataAsync();
}

Без асинхронности / ожидания: 

[HttpGet]
public Task<IActionResult> GetSomeDataAsync()
{
   return someService.GetSomeDataAsync();
}

Какой из этих двух лучше? Ключевым моментом здесь является то, что существует только 1 вызов другого асинхронного c метода (someService.GetSomeDataAsync()).

Ответы [ 4 ]

2 голосов
/ 11 апреля 2020

Различия между ними - в сценарии "только один асин c вещь" - тонки и в основном вращаются вокруг исключений, в частности: что происходит, если выбрасывается исключение вместо возвращение ошибочной задачи и b: особенности трассировки стека в любом сценарии исключения.

На самом деле, здесь все будет хорошо, но я бы оставил это простым и использовал синтаксис await в большинстве случаев. код приложения (а обработчик веб-запросов верхнего уровня определенно является кодом приложения). Здесь есть небольшие аппаратные издержки, но на уровне приложения , это действительно ничего, поэтому не беспокойтесь об этом.

Если, однако, вы писали библиотечная функция , которая вызывается сотни или тысячи раз за запрос (сетевой ввод-вывод, обработка строк и т. д. c) - , тогда стоит подумать о более агрессивном (и более ручные) способы оптимизации задач машины.

0 голосов
/ 11 апреля 2020

Согласно ASP. NET Базовые рекомендации по производительности ядра из ASP. NET команда:

Избегать блокировки вызовов

ASP. NET Основные приложения должны быть рассчитаны на одновременную обработку множества запросов. Асинхронные API позволяют небольшому пулу потоков обрабатывать тысячи одновременных запросов, не дожидаясь блокирования вызовов. Вместо ожидания выполнения длительной синхронной задачи поток может работать с другим запросом.

Распространенная проблема производительности в ASP. NET Основные приложения блокируют вызовы, которые могут быть асинхронными. Многие синхронные блокирующие вызовы приводят к истощению пула потоков и уменьшению времени отклика.

  • Делают пути горячего кода асинхронными.
  • Асинхронно работают с API доступа к данным, ввода-вывода и API длительных операций если асинхронный API доступен. Не используйте Task.Run, чтобы сделать API-интерфейс синхронным асинхронным.
  • Сделать действия контроллера / страницы бритвы асинхронными. Весь стек вызовов является асинхронным, чтобы использовать преимущества асинхронных / ожидающих шаблонов.

Избегать синхронного чтения или записи в теле HttpRequest / HttpResponse

Все I / O в ASP. NET Ядро асинхронно. Серверы реализуют интерфейс Stream, который имеет как синхронные, так и асинхронные перегрузки. Асинхронные должны быть предпочтительными, чтобы избежать блокировки потоков пула потоков. Блокировка потоков может привести к истощению пула потоков.

Предпочтение ReadFormAsyn c, а не Request.Form

Использование HttpContext.Request.ReadFormAsyn c вместо HttpContext.Request .FORM. HttpContext.Request.Form можно безопасно читать только при следующих условиях:

  • Форма была прочитана при вызове ReadFormAsyn c и
  • Кэшированное значение формы чтение с использованием HttpContext.Request.Form

Оптимизация доступа к данным и ввод-вывод

Взаимодействия с хранилищем данных и другими удаленными службами часто являются самыми медленными частями ASP. NET Базовое приложение. Эффективное чтение и запись данных крайне важны для хорошей производительности.

  • Вызывайте все API доступа к данным асинхронно.
0 голосов
/ 11 апреля 2020

Трудно быть абсолютно уверенным, если asyn c -wait помогает или мешает вашему методу действия контроллера (так как вам нужно было бы протестировать его с различными нагрузками), но, как общее правило любые контроллеры, которые обращаются к базе данных, файловой системе или другому удаленному API, должны быть асинхронными, а контроллеры, выполняющие простые вычисления в памяти, могут оставаться синхронными. Асин c вызовы добавляют немного (но очень мало) накладных расходов, поэтому, если сомневаетесь, go асинхронно.

0 голосов
/ 11 апреля 2020

Рекомендуется возвращать asyn c методы ... asyn c.

Это называется asyn c, см. Рекомендации MSDN:

https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/march/async-await-best-practices-in-asynchronous-programming

...