Использование Task.WhenAll для нескольких асинхронных и поддельных асинхронных методов

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

Оборачивание синхронного метода в Task.Run - не лучшая практика (см. Должен ли я предоставлять асинхронные оболочки для синхронных методов?). Это может сработать для вас, если торговля дополнительными потоками для такого поведения приемлема для вашего случая.

Если у вас осталась только одна синхронная операция, вы можете вместо этого сохранить ее синхронной и дождаться остальных в конце синхронного шага, сохраняя этот дополнительный поток:

var dataATask = _dataARepository.GetDataAsync();
var dataBTaskResult = _dataBRepository.GetData();
await Task.WhenAll(dataATask); // or just await dataATask if you have only one.
var viewModel = new ViewModel(dataATask.Result, dataBTaskResult);

Рассмотрим эти два подхода.

Оригинал:

public async Task<ActionResult> Foo() 
{
    var dataATask = _dataARepository.GetDataAsync();
    var dataBTask = Task.Run(_dataBRepository.GetData());
    await Task.WhenAll(dataATask, dataBTask);
    var viewModel = new ViewModel(dataATask.Result, dataBTask.Result);
    return View(viewModel);
}

^ Эта версия создаст новый поток для вызова _dataBRepository.GetData(). Дополнительный поток будет заблокирован до завершения вызова. Ожидая завершения дополнительного потока, основной поток вернет управление конвейеру ASP.NET, где он может обработать запрос другого пользователя.

Разные:

public async Task<ActionResult> Foo() 
{
    var dataATask = _dataARepository.GetDataAsync();
    var dataBResult = _dataBRepository.GetData();
    await dataATask;
    var viewModel = new ViewModel(dataATask.Result, dataBResult);
    return View(viewModel);
}

^ Эта версия не создает отдельную ветку для dataBRepository.GetData(). Но он блокирует основной поток.

Итак, ваш выбор:

1. Разверните другой поток, чтобы вы могли передать основной поток какой-либо другой задаче.
2. Держитесь за основную нить. Если какой-то другой задаче нужен поток, он должен будет развернуть свой собственный.

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

С другой стороны, если для действия требуются две или более синхронных серверных транзакции, исходный вариант завершится быстрее, поскольку они могут выполняться параллельно. При условии, что они это поддерживают. Если внутренние транзакции являются транзакциями базы данных и используют одну и ту же базу данных, они могут блокировать друг друга, и в этом случае вы все равно не увидите никакой выгоды.

Помимо Алексей Левенков упомянул об открытии синхронных оберток для асинхронных методов, использование Task.Run в приложении ASP.NET принесет больше вреда, чем пользы. Каждый Task.Run вызывает 2 планирования пула потоков и переключение контекста без каких-либо преимуществ.

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

Сравнивать:

async Task<int> ProcessAsync()
{
    var task = Task.Run(() => DoSomeHeavyCalculations());
    int calculationResult = await task;
    return calculationResult;
}

с участием

int ProcessAsync()
{
    return DoSomeHeavyCalculations();
}

Помимо того, что асинхронная функция использует больше интеллектуальных ресурсов, она ограничивает повторное использование функции: ее могут использовать только вызывающие асинхронные вызовы. Позвольте вашему абоненту решить, хочет ли он звонить вам асинхронно или нет. Если ему также нечего делать, кроме как ждать, он может позволить своему абоненту решить и т. д.

Кстати, это именно то, что делает GetData: он не заставляет вызывающих абонентов, таких как вы, быть асинхронными, он дает вам свободу называть его синхронным или использовать Task.Run, чтобы называть его асинхронным.

Однако, если у вашей функции есть чем заняться во время тяжелых вычислений, это может быть полезно:

async Task<int> ProcessAsync()
{
    var task = Task.Run(() => DoSomeHeavyCalculations());

    // while the calculations are being performed, do something else:
    DoSomethingElse();

    return await task;
}

В вашем примере: если есть только один «тяжелый расчет», сделайте это самостоятельно. Если есть несколько тяжелых расчетов, вы можете рассмотреть возможность использования Task.Run. Но не просто приказывайте другим потокам что-то делать, ничего не делая сами.