Эффективно используйте async / await с веб-API ASP.NET

Я пытаюсь использовать async/awaitфункцию ASP.NET в своем проекте веб-API. Я не очень уверен, повлияет ли это на производительность моей службы веб-API. Ниже представлен рабочий процесс и пример кода из моего приложения.

Рабочий процесс:

Приложение пользовательского интерфейса → Конечная точка веб-API (контроллер) → Метод вызова на уровне службы веб-API → Вызов другой внешней веб-службы. (Здесь у нас есть взаимодействия с БД и т. Д.)

контроллер:

public async Task<IHttpActionResult> GetCountries()
{
    var allCountrys = await CountryDataService.ReturnAllCountries();

    if (allCountrys.Success)
    {
        return Ok(allCountrys.Domain);
    }

    return InternalServerError();
}

Уровень обслуживания:

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountries()
{
    var response = _service.Process<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");

    return Task.FromResult(response);
}

Я проверил приведенный выше код и работает. Но я не уверен, что это правильное использование async/await. Пожалуйста, поделитесь своими мыслями.

Я не очень уверен, повлияет ли это на производительность моего API.

Помните, что основное преимущество асинхронного кода на стороне сервера - это масштабируемость . Это не заставит ваши запросы работать быстрее. В статье об ASP.NET я рассмотрю несколько asyncвопросов, которые следует учитывать.async .

Я думаю, что ваш вариант использования (вызов других API) хорошо подходит для асинхронного кода, просто имейте в виду, что «асинхронный» не означает «быстрее». Лучший подход - сначала сделать ваш пользовательский интерфейс адаптивным и асинхронным; это заставит ваше приложение почувствовать быстрее , даже если это немного медленнее.

Что касается кода, это не асинхронно:

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountries()
{
  var response = _service.Process<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
  return Task.FromResult(response);
}

Вам потребуется действительно асинхронная реализация, чтобы получить преимущества масштабируемости async:

public async Task<BackOfficeResponse<List<Country>>> ReturnAllCountriesAsync()
{
  return await _service.ProcessAsync<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
}

Или (если ваша логика в этом методе действительно сквозная):

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountriesAsync()
{
  return _service.ProcessAsync<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
}

Учтите, что так легче работать «изнутри наружу», чем «снаружи внутрь». Другими словами, не начинайте с действия асинхронного контроллера, а затем заставляйте нижестоящие методы быть асинхронными. Вместо этого определите естественно асинхронные операции (вызов внешних API-интерфейсов, запросы к базе данных и т. Д.) И сделайте их асинхронными на самом низком уровне вначале ( Service.ProcessAsync). Тогда пустьasync потоку просочиться, сделав действия вашего контроллера асинхронными в качестве последнего шага.

И ни при каких обстоятельствах нельзя использовать Task.Runв этом сценарии.

Это правильно, но, возможно, бесполезно.

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

Например, если уровень сервиса выполнял операции БД с Entity Framework, который поддерживает асинхронные вызовы:

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountries()
{
    using (db = myDBContext.Get()) {
      var list = await db.Countries.Where(condition).ToListAsync();

       return list;
    }
}

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

Await, как правило, требует полного упразднения: очень сложно приспособиться к существующей системе.

Вы не используете async / await эффективно, потому что поток запроса будет заблокирован при выполнении синхронного методаReturnAllCountries()

Поток, назначенный для обработки запроса, будет бездействовать, пока ReturnAllCountries() выполняет свою работу.

Если вы можете реализовать ReturnAllCountries()асинхронность, вы увидите преимущества масштабируемости. Это связано с тем, что поток может быть возвращен в пул потоков .NET для обработки другого запроса во время ReturnAllCountries()выполнения. Это позволит вашей службе иметь более высокую пропускную способность за счет более эффективного использования потоков.

Я бы изменил ваш уровень обслуживания на:

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountries()
{
    return Task.Run(() =>
    {
        return _service.Process<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
    }      
}

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

При таком подходе вы заключаете потенциально медленный вызов в объект Task, запускаете его и возвращаете для ожидания. Теперь вы можете ожидать Task.