18
Karma
36.9
Rating
1
Subscribers
Юрий Пастушенко @ypastushenko

.net разработчик, Dodo Pizza

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Да, что-то я погорячился. Вспомнил про примеры с наносекундами и решил, что оверхед не растет с ростом времени запроса.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Спасибо за советы. У нас сейчас как раз висит задачка на профилирование одно из сервисов. Попробуем сделать с PerfView.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Очень зависит от библиотеки. Например, коннектору к базе данных вполне стоит быть полностью асинхронным.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+2
10 милисекунд — это где-то на три-четыре порядка больше, чем время, уходящее на создание асинхронщины. В этом случае можно вообще не волноваться.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
Вообще вы, конечно правы в том, что async — это не панацея, и переводить решение на async просто потому что так сейчас модно, скорее всего не стоит. Однако, если ASP.NET решение упирается в пул потоков стоит наряду с увеличением пула рассмотреть вариант, при котором на hot path все вызовы будут полностью асинхронными.

Кроме того, набирают популярность managed решения, в которых у юзеров нет доступа к размеру пула потоков.

Я бы смотрел на async/await в ASP.NET так: микрософт предложил нам легкий способ работы с асинхронным кодом, который позволяет малой кровью подготовиться к хайлоаду «из коробки». По началу, он был кривой и косой, но уже в ASP.NET Core с ним стало вполне приятно работать и почти все известные проблемы убрали.

Кстати, поделитесь опытом: как вы с помощью PerfView пришли к выводу, что при использовании async/await сильный оверхед?

И еще вопрос:
Если же они работают медленно (>100мс) — на сервер никакой серьёзной нагрузки всё равно не создать

Можете пояснить: почему не создать?

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0

Справедливо. Поэтому Клэри и советует использовать ConfigureAwait (false) в библиотеках.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0

Всё правильно. Здесь отвязывается от контекста Task, который создается в StartWork, но Task, возвращаемый Task.Delay() всё еще привязан к контексту. Если перенести ConfigureAwait(false) в MyDelay, то дедлока не будет.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
Этот котик часть статьи) Картинка какбы говорит нам, что не нужно использовать Wait() без причины, иначе котику будет не хорошо)

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
ConfigureAwait(false) вообще отвязывает операцию от контекста синхронизации и отправляет ее в пул потоков. SynchronizationContext.Current становится равным null.
После ConfigureAwait(false) снимаются все ограничения наложенные контекстом ранее.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Да, тут больше речь о методах, которые пробрасывают таски дальше.

Отдельное спасибо за ссылку на Клэри :) Этот пост я как-то пропустил(

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+4
Не просто лучше, а нужно выполнять синхронно. Но что если, например, нужно реализовать метод интерфейса, который возвращает Task?

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
Да, статические анализаторы — хорошая штука. Но инструментами нужно пользоваться с умом, понимая, почему они считают код ошибочным.
1