Pull to refresh

Comments 13

Интересно, но не знаю как это можно применить в моем случае, когда проекты очень легкие

Вы можете начать выпихивать из ORM все сразу в поток. В новом ASP.NET Core это не должно создавать дополнительных буферов. На небольших объемах разницы вы не заметите конечно, но научитесь использовать технологию и когда потребуется стримить дофига вы уже будете знать что делать.

для клиента всё верно

для сервера "Для сервера

Масштабируемость: вы освобождаете потоки,"

не верно

А как, по-вашему верно?

PS Я бы написал "Масштабируемость: вы не блокируете потоки". Это — точная (AFAIK)формулировка. И это — почти одно и то же, что и та, против которой вы возражаете.

А что не так?

Попробуйте отправить 10 млрд одинаковых HTTP-запросов:

  1. С использованием асинхронных методов.

  2. С использованием классических тредов.

Сравните использование CPU, потоки которого освобождаются от тонны переключений контекста.

А теперь добавьте в эти HTTP-запросы запросы к БД длительностью от 100мс, исправьте ошибки в многопоточности при использовании тредов и давайте тоже сравним время, затраченное на разработку и пропускную способность сервера. Время на разработку умножьте на рыночную ставку разработчика, умеющего "в треды".

Добавление io-потоков в asyncio приложение лишь усилит демонстрационный эффект превосходства подхода с асинхронным io.

Всё остальное не очень понял. Разработчика умеющего в треды, пока ещё, найти проще, чем разработчика умеющего в async/await.

Я видимо неверно прочитал ваш оригинальный комментарий. Про async/cpu-bound мы одно и то же написали в итоге. Пардоньте)

"Про Стивена Клири можно сказать «он всерьез занялся многопоточным программированием еще до того, как это стало мейнстримом». "

его еще на свете не было, "как это стало мейнстримом"

и еще после него появилась байка которая как видим до сих пор жива "Для сервера

Масштабируемость: вы освобождаете потоки"

Почему байка? С чего Вы взяли, что это не верно?

Sign up to leave a comment.