Асинк и ждать: они плохие?

Ответ 1

Есть ли что-то глупо с этим методом? Обратите внимание, что когда мы весь метод для не-асинхронных методов, мы получили более высокую производительность.

Я вижу, по крайней мере, две вещи идут не так:

public static async Task<T> GetApiResponse<T>(object parameters, string action, CancellationToken ctk)
{
        using (var httpClient = new HttpClient())
        {
            httpClient.BaseAddress = new Uri(BaseApiAddress);

            var formatter = new JsonMediaTypeFormatter();

            return
                await
                    httpClient.PostAsJsonAsync(action, parameters, ctk)
                        .ContinueWith(x => x.Result.Content
                            .ReadAsAsync<T>(new[] { formatter }).Result, ctk);
        }
    }

Во-первых, лямбда, которую вы переходите на ContinueWith, блокирует:

x => x.Result.Content.ReadAsAsync<T>(new[] { formatter }).Result

Это эквивалентно:

x => { 
    var task = x.Result.Content.ReadAsAsync<T>(new[] { formatter });
    task.Wait();
    return task.Result;
};

Таким образом, вы блокируете поток пула, на котором выполняется lambda. Это эффективно уничтожает преимущество асинхронного API ReadAsAsync и снижает масштабируемость вашего веб-приложения, Остерегайтесь других мест, подобных этому в вашем коде.

Во-вторых, запрос ASP.NET обрабатывается потоком сервера со специальным контекстом синхронизации, установленным на нем, AspNetSynchronizationContext. Когда вы используете await для продолжения, обратный вызов продолжения будет отправлен в тот же контекст синхронизации, код, сгенерированный компилятором, позаботится об этом. OTOH, когда вы используете ContinueWith, это происходит не автоматически.

Таким образом, вам необходимо явно указать правильный планировщик задач, удалить блокировку .Result (это вернет задачу) и Unwrap вложенную задачу:

return
    await
        httpClient.PostAsJsonAsync(action, parameters, ctk).ContinueWith(
            x => x.Result.Content.ReadAsAsync<T>(new[] { formatter }), 
            ctk,
            TaskContinuationOptions.None, 
            TaskScheduler.FromCurrentSynchronizationContext()).Unwrap();

Тем не менее, вам действительно не нужна такая сложная сложность ContinueWith здесь:

var x = await httpClient.PostAsJsonAsync(action, parameters, ctk);
return await x.Content.ReadAsAsync<T>(new[] { formatter });

Следующая статья Стивена Туба очень важна:

"Async Performance: Понимание затрат Async и Await" .

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

Вам почти никогда не нужно смешивать await и ContinueWith, вы должны придерживаться await. В принципе, если вы используете async, это должно быть async "all the way" .

Для среды выполнения ASP.NET MVC/Web API на стороне сервера это просто означает, что метод контроллера должен быть async и возвращать Task или Task<>, проверить this. ASP.NET отслеживает ожидающие задачи для заданного HTTP-запроса. Запрос не будет завершен, пока все задачи не будут завершены.

Если вам действительно нужно вызвать метод async из синхронного метода в ASP.NET, вы можете использовать AsyncManager как this для регистрации ожидающей задачи. Для классического ASP.NET вы можете использовать PageAsyncTask.

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

Для приложений пользовательского интерфейса на стороне клиента возможны разные сценарии для вызова метода async из синхронного метода. Например, вы можете использовать ContinueWith(action, TaskScheduler.FromCurrentSynchronizationContext()) и запустить событие завершения из action (например this).

Ответ 2

async и ожидание не должны создавать большое количество потоков, особенно не только с 16 пользователями. Фактически, это должно помочь вам лучше использовать потоки. Цель async и ждать в MVC - фактически отказаться от потока пула потоков, когда он занят обработкой IO связанных задач. Это говорит мне, что вы делаете что-то глупое, например, нерестилища, а затем ожидаете бесконечно.

Тем не менее, 900 потоков не очень много, и если они используют 100% -ный процессор, то они не ждут.. они что-то пережевывают. Это то, что вы должны изучать. Вы сказали, что используете такие инструменты, как NewRelic, и что они указывают на источник использования этого процессора? Какие методы?

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

Во-вторых, возьмите копию своего приложения и начните извлечения материала, а затем выполните тесты против него. Посмотрите, можете ли вы отследить, где именно проблема.

Ответ 3

Существует много материала для обсуждения.

Прежде всего, async/await может помочь вам, когда у вашего приложения практически нет бизнес-логики. Я имею в виду, что точка async/await состоит в том, чтобы не иметь много потоков в спящем режиме, ожидая чего-то, в основном, некоторых IO, например. запросы базы данных (и выборки). Если ваше приложение использует огромную бизнес-логику с использованием процессора на 100%, async/wait не поможет вам.

Проблема 900 потоков заключается в том, что они неэффективны - если они работают одновременно. Дело в том, что лучше иметь такое количество "деловых" потоков, поскольку у вас на сервере есть ядра/процессоры. Причина - переключение контекста потока, блокировка и т.д. Существует множество систем, таких как шаблон LMAX distribuptor или Redis, которые обрабатывают данные в одном потоке (или одном потоке на ядро). Это просто лучше, поскольку вам не нужно обрабатывать блокировку.

Как достичь описанного подхода? Посмотрите на прерыватель, загрузите входящие запросы и обработайте их один за другим, а не параллельно.

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

Как он работает в основном: есть поток, который считывает байты из сети - в основном только один. После поступления некоторого запроса этот поток считывает данные. Существует также ограниченный пул потоков работников, который обрабатывает запросы. Точка async заключается в том, что как только один поток обработки ожидает чего-то, в основном io, db, поток возвращается в опросе и может использоваться для другого запроса. Когда IO-ответ готов, для завершения обработки используется поток из пула. Это способ, которым вы можете использовать несколько потоков для запроса на тысячу серверов за секунду.

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