Асинхронный Python-код медленнее обычного кода! Ааа!!1один. Aiohttp VS синхронные фреймворки

[@t0digital]

Мой курс «Хардкорная веб-разработка» - course.to.digital Вжух!

[@Семен-к6ж3п]

Очень здорово придумал подачу. Поставлена задача и все ручками решается прямо при зрителе. На мой взгляд очень полезно, особенно начинающим.

[@t0digital]

Спасибо! Рад, что полезно!

[@starlightx3052]

Вспомнился прекрасный ответ со stackoverflow: if io_bound: if io_very_slow: print("Use Asyncio") else: print("Use Threads") else: print("Multi Processing")

[@t0digital]

Да!

[@karlzinher4181]

что за выравнивание самовольное не по пепу ? :D :atata

[@Uni-Coder]

Я бы написал "Use threads OR asyncio if you are used to", при относительно быстром IO можно и async использовать, если вам привычнее. Да и вообще, в клиент-серверных приложениях в современном контексте async должен быть по умолчанию.

[@ziminf1997]

@@karlzinher4181 Почему не по пепу?

[@karlzinher4181]

@@ziminf1997 не заморачивайтесь :) визуально три пробела показывает %) а по факту 4ре))) верстка в хроме зачетная тут

[@ФедорГоловин-с8к]

Поигрался с этими тестами и обнаружил, что выдаваемые ими RPS прямо пропорциональны доступному количеству соединений с БД. В тестах для синхронных фреймворков используется пул psycopg2, но в них он абсолютно бесполезен. Каждый воркер будет использовать лишь одно соединение из пула: взял соединение, выполнял запрос, вернул соединение в пул. Т.о. получается потолок для синхронных фреймворков: 12 воркеров * 1 соединение * 5 запросов в секунду (по 0.2) = 60 rps. С асинхронными фреймворками ситуация иная. После того, как воркер взял соединение из пула и отправил в него запрос он не ждёт ответ из БД, а берет второе соединение, третье и т.д., пока не загрузит весь свой пул работой. По умолчанию, максимальный размер пула aiopg составляет 10 соединений. Итог: для асинхронных соединений потолок в этих тестах составляет: 12 воркеров * 10 соединений * 5 запросов в секунду (по 0.2) = 600 rps. В свете этого, цифры, показанные тестами, не значат ничего конкретного, т.к. получены в разных условиях. Зато они отлично отражают подход. Ради смеха, я решил сравнять количество доступных соединений к БД для двух фреймворков. Для асинхронного Sanic я использовал 4 воркера, то есть 40 соединений. Для Flask пришлось создать 40 воркеров =) В обоих кейсах я получил ожидаемые 200rps. Но какой ценой! 40 процессов для Flask стоили мне в сумме 900Mb памяти. А 4 процесса Sanic - 90Mb.

[@ivantolkachev]

Тоже самое хотел написать, просто нужно в синхрон добавить воркеров и можно получить такой же результат.

[@КириллЧе-я5ы]

Прекрасный анализ. Спасибо

[@КириллЧе-я5ы]

То есть получается из-за того, что сипитон однопоточный, поэтому синх использует только один тред в воркере… или нет? Я не питонист…

[@romantsaregorodtsev9993]

Это что получается. Опять нужно головой думать исходя из задачи вместо того, чтобы использовать "самый быстрый фреймворк". Во дела...

[@ВладимирМиллер-о5з]

И использовать языки для нужных задач. Во дела)) Согласен)) А то получается, словно унитаз вилкой чистить)))

[@GexPlayerMD]

Ага. Неприятная ситуация для тех, кто пишет свои проекты бездумной копипастой с гугла...

[@allallall2321]

Смотрите ХАудихо там все ответы на вопросы!

[@dmitryponyatov2158]

или сменить платформу на Elixir/Phoenix, тогда точно придётся думать -- в языке нет циклов 8) но того стоит - полноценная многозадачка, а nginx перед ним _мешает_ работать

[@lalalf4535]

@@ВладимирМиллер-о5з класс

[@Vlad-user-hjcgxffxhnjvhhcy]

11:00 - 11:20 Сыграно АГОООНЬ! Аж слёзка подкатила! )) Классный канал!

[@_t4g]

Твои ролики это топ)они странным образом побуждают после просмотра разобраться самому и углубиться в тему ролика!Это по настоящему прекрасно, спасибо тебе.

[@t0digital]

Спасибо! Эта самая правильная реакция:)!

[@ase_ventura]

Ой, вот прям в нужное время.. Вот как раз таких крутых видео не хватает. А то везде видео с маркетинговыми заголовками, а здесь всё круто и по делу. Спасибо за контент! Продолжайте в том же духе.

[@kannykl7575]

Пришёл не по уведомлению, а по зову сердца Спасибо за топ контент!

[@t0digital]

спасибооо!

[@РустамГазетдинов-б9й]

@@t0digital Привет, в видео по типу прошлого, про многопоточность, мне кажется было бы лучше вставлять картинки для большего понимания, подобные темы легче воспринимать с помощью изображений. Успехов)

[@t0digital]

@@РустамГазетдинов-б9й да, согласен. Дорасту до монтажера, видосы вообще станут вкусняшкой:)

[@TeppopucT]

Разрушители мифов в мире IT. Классная демонстрация! Спасибо!

[@SinAzucarAnadido]

На синхронном сервере при 12 воркерах и 200 мс теоретический предел - 60 рпс. Чтобы выжать из него больше, надо поднимать число воркеров

[@79fz270704]

Лайк за хорошие рекомендации!

[@АлександрКостромин-к4х]

Спасибо большое дружище! Очень познавательно👍

[@МаксимМаксимов-ч9т]

Очень грамотный и доходчивый контент.

[@t0digital]

спасибо!

[@ВладимирПетров-г1я]

Спасибо за труд! Смотрю с удовольствием.

[@rumartru]

На многих ресурсах видел перевод статьи про асинхронность. Спасибо за разбор!

[@t0digital]

Рад, что полезно!

[@1ДмитрийСергеев]

Спасибо за видео! Очень информативно

[@kubenet]

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

[@georgestatefield]

Это видео было полезным, как и другие Алексей - молодец!

[@Nsky-024]

Интересно, спасибо!

[@t0digital]

Спасибо!

[@gnompirogov9259]

спасибо за подробный разбор

[@sevashpun]

Спасибо за видео!

[@LewaSGN]

Очень полезно и доходчиво! Спасибо, буду иметь ввиду.

[@t0digital]

💪💪💪

[@rkozom]

Круто! Спасибо!

[@drygdryg2]

Спасибо, очень интересно и полезно. Было бы интересно увидеть тест с участием asyncpg вместо aiopg. Также интересно, как правильно профилировать приложения, чтобы понимать, на что уходит больше всего процессорного времени: на ввод-вывод, либо на вычисления, и сколько на что из этого уходит.

[@staskomar]

Чувак жги, всегда лайк))

[@t0digital]

спасибооо!

[@StoGigovo]

Алексей, продолжай, я на твоих видео такими темпами стану Мидлом!)

[@adilzhan8282]

Очень интересное и полезное видео! Буду ждать еще подобных видео!) И есть просьба, если возможно, пожалуйста объясняй, кратко, всякие термины, которые могут быть кому-то не известно)) Я например не знаю что такое трейды( Я понимаю что есть гугл, но просто отвлекаться что бы найти и понять каждый термин как-то не очень)

[@t0digital]

в прошлом видео как раз было о том, что такое треды, процессы, асинхронность, основные термины

[@adilzhan8282]

@@t0digital а, оу, я его смотрел, но успел забыть) Спасибо!

[@АнтонинаСмет]

Классное видео, спасибо

[@evgenibasov9545]

Офигенно 👍

[@volodiaagadjanov7087]

Это слишком очевидно, логично, что при синхронном выполнении эти 200мс будут суммироваться с временем выполнения А в ассинхронном - эти 200мм будут раскидываться на количество потоков

[@Bisirsky]

Я вот тоже не понял. А нельзя было реальные запросы потестить(?)

[@staticintsolo1939]

как нельзя кстати сейчас стоит задача как то ускорить процесс отправки запросов к смтп серверу, а то после 30-ого скорость растет будто по факториалу, и тут контент.. годнота!

[@denissemikin2683]

Досмотрел видео до конца. Да, aiohttp работает хорошо когда доставили sleep, но заметьте что wrk на aiohttp возвращает 59 респонсов не с 200-300 статус кодами. Поэтому он показал цифры быстрее конечно, но при этом респонсы некоторые были невалидные вообще.

[@ЮрийПопов-л6я]

Круто! Ума нет считай - тормоз во всем!!!!! Видео очень полезно понравилось

[@blackcatdevel0per]

17:57 А как же asyncqt? Например у меня в синхронном qt может подвисать интерфейс при выполнении какой-то задачи кнопкой и конечно я могу обойтись тредами и многопроцессорностью, но в некоторых задачах(даже не связанных с сетью) асинхронность сильно экономит ресурсы и работает лучше, но тут уже всё зависит от конкретной задачи

[@maxshishkn]

Лёха все супер, продолжай радовать котанов мяу 😻

[@ilyasbutaev3830]

Было бы интересно послушать про event loop от вас

[@ИльяЖеребцов-д4х]

17:45 мне кажется это свойственно не только питону, это в общем так работает

[@ФедорКосолапов-р6д]

Мхатовская пауза в середине очень понравилась! Аж сердце замерло, неужели думаю,... и в самом деле... асинхронный Питон полный отстой... Ан нет! Живём-с :)

[@vb3039]

Очень интерестно :)

[@N5O1]

13:32 я не питонист, но мне интересно как это работает. окей, постгрес спит 200мс прежде отдать ответ, но по какой причине произошло ускорение? что такого произошло в коде, что асинхронный код начал работать в 8 раз быстрее?

[@t0digital]

Более эффективное использование каждого ядра процессора. Когда есть ожидание 200мс ожидания ответов от сети (или какое-то иное ощутимое ожидание IO операций, не обязательно такое большое), то можно или ничего не делать в них, или обрабатывать другие HTTP-запросы в это время. Если идёт обработка других запросов - то и больший RPS получаем, requests per second, запросов в секунду

[@Uni-Coder]

Асинхрон же придумали именно для IO-нагруженных задач, естественно, в них и надо тестировать и сравнивать (мелким шрифтом: формально, есть асинхронные операции и для CPU-нагруженных задач, см. C#, но мы же знаем, что многопоточность и CPU-нагруженные задачи - это не про Python). Упс, написал до того, как просмотрел до 16:20 и тем более 17:58. Да, просто полностью согласен

[@bolatmukashev2830]

А можно видео про то чем отличается многопроцессинг, многопоточность и асинхронность? С примерами на Python

[@OlegKuzminov]

Шикарный момент на, 11:10! :)

[@magictearsasunder]

Хотелось бы посмотреть по ASGI и WSGI в джанге.

[@t0digital]

Планирую такой материал

[@yaroshchenko_creative]

Хорошо что досмотрел а то уже расстроился.

[@ЕвгенийКуц-у7х]

Спасибо за материал! Интересно посмотреть меняется ли ситуация при использовании микросервисов в докере. И скейлинг горизонтальный. Что лучше поместить в этом случае в докер, aio или стандартпый фреймворк. Для увеличения показателей qps.

[@vrabosh]

1. Я как понял форк запускает несколько скриптов, т.е. подымает несколько серверов и каждому по очереди скармливает http даннные запросы.. если так, то запусти на синхроно, 100 форков и посмотри что будет. т.е. пока там 200мс простаивает, другие скрипты же могут выполнятся.. 2. Когда идет синхроная обработка, то и запросы в БД идут синхроно, а значит БД не загружена, и будет выполнятся по той скорости как будто 12 запросов в БД одновременно, что снижает нагрузку на процессор и будет быстрее выполнятся.. как в асинхроности это может быть 1000 запросов к БД, что реально будет делать 200мс... Все выше доводы говорят о том, что тесты не 100% верны. Еслиб вы написали реально реализацию с БД, где от одного запроса идет выполнения скрипта 200мс, хотябы просто селект без индексов, тогда бы тесты былибы адекватными. А пока первый вариант где синхроность выглядит более реалистично, посути на реальном примере, пускай и банальном.. т.е. если у когото такой банальный пример, простой чат-бот, то синхроность как я понял лучший вариант.

[@ВикторГиль-ф2ф]

Там слишком много неизвестных. Где находится база данных (на том же компьютере или нет) и как реализована задержка в селекте, где расположен источник запросов... От этого зависит распределение нагрузки по ядрам. И почему именно 10 или 12 ? По числу ядер надо создавать (и клиента в том числе). Потому как увеличение количества процессов более количества ядер приведет лишь к увеличению накладных расходов на переключение и снижению быстродействия. А поскольку в асинхронном режиме нет переключения потоков, то и лишних затрат на переключение контекста нет, но это абсолютно не значит, что асинхронное быстрее. Надо выяснять реализацию, как построены фреймворки.... без этого это "гадание на кофейной гуще".

[@vrabosh]

@@ВикторГиль-ф2ф да ты прав.

[@prepyev]

Спасибо, как раз вовремя! P.S. На столе PocketBook 740?

[@t0digital]

Он самый:)

[@prepyev]

@@t0digital Хе-Хе, долго искал эту обложку под принт на домах у нас у Бутово, узнал :))

[@t0digital]

@@prepyev а что за принт на домах у Бутово?

[@prepyev]

​@@t0digital ​ Чет мне как-то показалось, видосы канала из офиса в БЦ "Лотос", вот и подумал может соседи. А принт вот этот etaloncity.ru/about/news/3238/ Кацусики Хокусая

[@t0digital]

@@prepyev о, не видел это принт на зданиях. Мне нравится эта картина, кайфовая. Видосы из Лотоса, да:)

[@demos998]

Очень полезно!!!

[@Денис3-ю2н]

Отличная работа!

[@t0digital]

спасибо!

[@FRA1T]

Диджитализируй! Уважаемый Алексей, с особым интересом смотрю все Ваши учебные видео-уроки и уже узнал очень много нового, за что Вам огромное человеческое спасибо! У меня есть вопрос касаемо вынесения бизнес-логики из вьюшек. Вы всё время твердите, что бизнес-логику нужно выносить в сервисы, например, с чем я очень хочу согласиться, но что делать, если вьюшки основаны на классах, а не на функциях (как во всех рассматриваемых Вами примерах)? Неужели такие методы, как get_queryset, get_context_data выкидываются? Как поступать в такой ситуации? Заранее благодарю за ответ! P.s. для примера вот такой метод: def get_queryset(self): return Movie.objects.all()

[@АлександрСереда-б4ж]

это, мягко говоря, странно выглядит, но в рамках примера - выносите в сервисы функцию def get_all_movies(): return Movie.objects.all() которую используйте в методах вьюхи и/или любого другого класса

[@FRA1T]

@@АлександрСереда-б4ж спасибо, но почему это странный вопрос? Обычный метод get_queryset. Значит, в этом методе мне нужно возвращать метод из вашего примера? def get_queryset(self): return get_all_movies()

[@АлександрСереда-б4ж]

@@FRA1T вопрос не странный. в рамках примера странно (на мой взгляд) выносить что то совсем элементарное, в отдельные функции/сервисы. При наличии какой то логики (хотя бы фильтрация) - да, это имеет смысл. А так да, вы все правильно поняли, в get_queryset возвращаете вызов метода, который вынесли в services

[@FRA1T]

@@АлександрСереда-б4ж благодарю за ответ, теперь чувствую себя лучше от знаний!

[@4cd99e]

Я думаю, что даже в примере, когда запрос долгий, можно сказать, что синхронный ВОЗМОЖНО будет быстрее. Стоит различить две ситуации: когда база данных находится на той же машине, что и сервис, и когда они разделены. Показанный пример - это пример, когда они разделены (запрос в бд не нагружает железо сервиса). Но если запрос в бд будет активно нагружать железо сервиса, асинхронные фреймворки не будут уже так себя комфортно чувствовать. Хотя много зависит от запроса: он может быть на чтение большого кол-во данных, а может на построение новой сложной структуры...

[@evermake-yt]

Как с курсом обстоят дела?

[@t0digital]

Образовательная программа будет, онлайн, разбитая по модулям, которые можно будет прорабатывать отдельно

[@d-mass-32]

Огромное спасибо за разъяснение!!! Ох уж эти холивары: придумывают синтетический тест, никак не соотносящийся с реальностью, получают какие-то результаты, не анализируют, а просто возводят в абсолют, и потом орут на весь мир, что это - гамно и это - гамно и мнение хрен оспоришь ! 😪

[@ИмяФамилия-в2г4ь]

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

[@maxsvetlychny8081]

Как всегда спаcибо за видео! Небольшой оффтоп вопрос - не страшно запускать код какого-то постороннего чувака под своим юзером? У меня обычно для этого заготовлена песочница на firejail. Это нормальное решение или паранойя?)

[@t0digital]

ну в целом паранойя лишней не бывает:)

[@zorik6470]

Ребят, что такое воркер простыми словами? В этих гуглах какие-то сложные формулировки :(

[@t0digital]

процесс, который выполняет основную работу. Work работать, worker работник. Сервер gunicorn, например, один главный процесс следит за живостью воркеров, а воркеры выполняют саму работу - обработку HTTP запросов.

[@zorik6470]

@@t0digital спасибо!

[@eb6006]

У тебя такто все темы интересные ))

[@t0digital]

Спасиб:) будем продолжать

[@vandriichuk]

Спасибо за видео. А чем записываете экран когда пишете код, чтобы было прозрачно?

[@t0digital]

Просто режим наложения слоя скринкаста какой-то в монтажке

[@Anatolii_V_Novikov]

Правильнее тестировать/измерять на реальном проекте, как есть. А синтетические тесты - как дополнение, на всякий случай (граничные случаи).

[@antonmullakhmetov707]

Спасибо!

[@Bandera_tut]

интересно-интересно, но, там же щас джанго асинхронный клепают, будет какое видео обсуждение об этом? или еще сами не пробывали тыкать туда?

[@t0digital]

Будет видео, но пока рано говорить об асинхронном джанго, и не факт, что когда-то об этом можно будет говорить полноценно

[@doskuloff]

В очередной раз спасибо Вам, Алексей! Ну а я все еще в комнате ожидания DRF😂

[@t0digital]

однажды будет и DRF

[@senatortre7326]

Диджитализируй! Раз пошла пляска (великолепная кстати) с асинхронном, можно скомбинировать темы и заменить дрф на ФастАпи

[@artemhrytsenko1353]

17:12 - синхронные*

[@dasturchininghayoti7910]

FastAPI, Sanic, Starlette?

[@AlexK544]

Фаст вроде на поверх старлет :) Так что , осталось только Sanic узнать куда поставить.

[@mandico21]

Как также перемещаться по файлам в Vim ?

[@t0digital]

gt, gT переход по вкладам в вим, если вы об этом

[@mandico21]

@@t0digital оо, спасибо )

[@DanielLuchin]

А что использовать если есть задача скопировать кучу файлов по smb?

[@МаксимСалий-п6ь]

Non-2xx or 3xx responses: 59 - для теста с aiohttp и эмуляцией запроса в базу 200 ms. Получается, что из 100 запросов с 200 статусом вернулся ответ для 41 запроса. Я правильно понимаю?

[@poematization]

В доках на aiohttp указывают, что гуникорн работает медленнее других решений. Интересно было бы увидеть тесты на это.

[@t0digital]

slightly, как они говорят. Без гуника настраивается - nginx и systemd, который стартует несколько процессов с aiohttp

[@АндрейЗевакин-щ8и]

@@t0digital Насколько будет лучше если Gunicorn запустить через aiohttp.GunicornUVLoopWebWorker, а aiopg заменить на asyncpg? )

[@cyrilanisimov]

Мораль - доверяй (статьям), но проверяй

[@t0digital]

так и есть

[@bladeserful]

А почему собственно при изменении запросов заново не подобрали количество воркеров? Так как запрос выполняется долго, то процесс выполняющий запрос почти не грузит систему. Соответственно банальное увеличение количества воркеров должно сильно улучшить текущие результаты синхронных систем, да и асинхронных тоже. Я требую продолжения банкета!

[@ДмитроМанжура]

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

[@t0digital]

Почему все тестят запросы в базу - потому что в стандартном веб проекте есть запросы в базу и они занимают бОльшую часть времени обработки запроса, что как раз является кейсом на неблокирующий ввод вывод. Мат операции - кейс на процессорные ядра, в не асинхронность.

[@ДмитроМанжура]

@@t0digital это я понимаю, но это дополнительная прослойка, за которую не отвечает язык программирования, если для селектов использовать nosql бд, производительность будет другая.

[@t0digital]

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

[@dmitryponyatov2158]

есть такой стек Eixir/Phoenix (язык поверх Эрланг-машины, лучшая многозадачность из всех языков) -- который специально был сделан авторами на замену Ruby/Rails можете по собственному опыту сравнить впечатления?

[@dmitryponyatov2158]

самый известный тул, написанный на Эрланг -- это RabbitMQ, известный своей эффективностью в проде

[@artemstroev3149]

Очень захотелось увидеть результат Django на sleep 0,2

[@КириллКириллович]

Кто такой worker и зачем он нужен? Понятно, что это рабочий, но он из какой такой шахты? Будете делать видео с подробностями об асинхронности?

[@t0digital]

Да

[@t0digital]

@@avazart614 да

[@КириллКириллович]

@@t0digital Спасибо!

[@t0digital]

@Avazart идея была в том числе в том, чтобы сохранить методику тестирования автора теста, понятно, что правильнее было бы тестировать, раскатав все на как минимум на 2 сервера, аппликейшн и бд

[@sorokousov]

В реальности, из 100 запросов 80 будут простыми. Поэтому использовать aiohttp нужно только там, где это действительно(!) нужно.

[@vrabosh]

да. надо комбинировать. Некоторые запросы типа insert delete на которых работа с БД заканчивается и ответ от них не важен, можно кидать в асинхроность. Также отпавка сообщения в телеграм тоже в асинхроность.

[@slukinkostja2064]

Все вроде бы так, да есть один нюанс. Вы бы количество воркеров во тором тесте для синхронного кода раз в 10 увеличили бы. Глядишь результат интересней мог получился.

[@mexico76]

Здравствуйте! А что вы можете сказать про asgi в django? Это ведь связано с асинхронностью, может это выход для данного фреймворка?

[@t0digital]

Джанго ведёт работу над переводом в асинхронность, но я не думаю, что в обозримом будущем джанго сможет стать полностью асинхронным и что вообще хочет этого

[@ИсламАбдукеримов-ъ9п]

Здравствуйте! У меня вопрос немного не по теме . Тут пару месяцев назад Гарвард выпустил новый курс бесплатный CS50 посвящённый веб-разаработке на JS и Python. Хотелось бы услышать ваше мнение об этом курсе.

[@t0digital]

Здравствуйте, не видел не проходил, но спасибо, что написали, возможно познакомлюсь

[@gooseman5578]

CS50 - это курс по Си. Дно, а не курс. Там подача такая, что до циклов добрались только на 5й лекции. И там уже от курса осталась треть сонного зала. kzbin.info/www/bejne/iYjChnawe7RqjpI

[@vladislavbychkov302]

Ты используешь Vim и в браузере?))

[@t0digital]

Да, vimium

[@vrabosh]

@@t0digital каждый раз когда тебя смотрю, в очередной раз задумываюсь, может реально vim поучить и недельку ему посвятить)

[@ruzin-kokoc]

Алексей - молоток! Однако, хотелось бы услышать еще объяснение "почему так". Попробую объяснить, как сам понимаю и почему считаю, что утверждение "асинхроный код работает быстрее" - это миф. Допускаю, что у моего объяснения много допущений и неточностей, тем не менее. Процессор - один, полезную нагрузку, которую надо посчитать - одна и та же. Тогда с какой стати задача будет решена быстрее, если ее решать "поперек", а не "вдоль"? Т.е. одна задача в принципе асинхронно не может быть решена быстрее чем синхронно. Тогда почему говорят, что асинхронно можно решать быстрее? Так говорят про поток задач. Асинхронное выполнение позволяет "пропустить" через процессор больше задач в единицу времени. Всегда? Нет. Если задачи завязаны на процессор - нет, не позволяет. А если на ввод/вывод - теоретически - да. Если мы сразу запустим N задач - каждая из которых будет ждать ввода-вывода, то N задач могут выполниться параллельно быстрее, чем если их решать последовательно одну за другой. А какими способами можно запустить параллельное решение задач? - процессы - треды - event-loop с epoll (async await) Разница между ними в накладных расходах (и удобстве программирования). В двух первых из них за переключением между задачами следит ОС. Она же гарантирует, что каждой задаче будет уделено какое-то время. В последнем - за переключением следите вы сами, организуя свое приложение. А можно ли не использовать async await, но устроить event-loop? Можно, например, используя greenlet'ы greenlet.readthedocs.io/ Какие накладные расходы? Запуск нового процесса это всегда: а) накладные расходы на память б) дополнительные (и не дешевые) системные вызовы. в) межпроцессное взаимодействие (передача задания и результатов) Треды чуть "легче"" и память разделяемая, но со своими "удобствами", например, в Python'е их сложно принудительно остановить снаружи (не из самого треда). Event-loop'ы самые "дешевые", но достаточно сложные в организации кода. Кроме всего прочего, еще нужно иметь ввиду GIL (Global Interpreter Lock), который не позволяет нескольким threads работать одновременно в Python. Касательно тестов, которые провел Алексей. У нас все запросы "одинаковые": запрос - пауза 200 мс - ответ. Async-await работает прекрасно и на одном ядре CPU можно выполнить хоть 10000 таких запросов в секунду. Т.е. каждый запрос потребляют 0.0001 CPU. Latency этих запросов будет ~200 мс (ожидание ввода-вывода). Теперь, представим себе, что каждому 100-у запросу требуется CPU на 2 секунды. Т.е. мы ожидаем что в среднем теперь требуется ~0.02 CPU. И мы можем ожидать выполнения ~50 запросов в секунду. Попробуем взглянуть, что произойдет с обработкой этих запросов в действительности. Первые 50 запросов, пришедших в первую секунду отдадутся через 200 мс, каждый. Вторый 50 запросов, пришедших во вторую секунду отдадутся через 200 мс, каждый, за исключением последнего, которые отдастся через 2 секунды. Третьи 50 запросов, пришедших в третью секунду отдадутся через 2 секунды, каждый, т.к. им придется ждать, пока 100-й запрос отдастся, а потом они смогут вернуть свой результат. Четвертые 50 запросов, пришедших в четвертую секунду отдадутся через 2 секунды, каждый, т.к. им тоже придется ждать, пока отработает 100-й запрос, А 200-й запрос задержится на 2 секунды. Все запросы за исключением первых 99 будут отдаваться теперь за 2 секунды вместо 200 мсек. Т.е. казалось бы async-await должен "помочь", но вместо этого, он "выравнивает" latency по самому медленному (запросу) (Строго говоря, если запросы приходят равномерно, то первые из 100 будут ждать 2 секунды, а последние всего около 200 мсек, т.е. в среднем все же меньше чем 2 секунды) Выводы: Я не к тому, что нельзя использовать async-await, но к тому, что написание таких обработчиков требует особой внимательности - ни один из них не должен быть CPU-bound - иначе все усилия могут потрачены впустую. Так надо использовать async-await? Не попробуешь - не узнаешь. Но если у вас разнообразные обработчики, то как минимум нужно CPU-bound обработчики искусственно прерывать, давая возможность "пропустить" IO-bound вперед. Это, в свою очередь не увеличивает читаемость кода. Вот пару видео от python-хакера David'а Beazley - будут полезны: kzbin.info/www/bejne/hZPXXqmDi8mAbtU kzbin.info/www/bejne/roDce5yEaN56nLc

[@user-ch76tcye4vvuu8]

Что тут у нас? 58 rq/sec... Было 12 потоков http сервера. Получается, что одновременно (параллельно) выполняется не более 12 запросов, остальные выстраиваются в очередь перед сервером. Каждый запрос выполняется 200мс => поток выполняет до 5 rq/sec. 12*5 = 60 rq/sec (минус 2 rq/sec на прочие потери). В асинхронном же поток, пока ждет результата от базы, уже выполняет следующий запрос. По максимуму утилизирует ресурсы.

[@nitroflap]

Чисто мне было бы интереснее про юнит тестинг в питоне. Ибо нагруженные сервера никто на питоне не будет делать, для этого вон есть Go, Java, C# и другие с рутинами и корутинами...

[@AlexK544]

К вопросу о асинхронности. Вот есть aiohttp сервер с 1м воркером. Клиент обратился, улетели запросы несколько апи, асинхронно вернулись, крастота! Но потом нужно выполнить синхронную операцию, например все это там как-нибудь пересчитать, например в Пандасе или нампи. Получается что эта синхронная операция убьет всю асинхронность воркера? Или как?

[@ilyastrojnov7627]

Выдели отдельный процесс(не поток) для расчетов и подкидывай ему данные

[@AlexK544]

@@ilyastrojnov7627 может быть есть пртмер как это реализовать? А то расчетов походу будет много, а запросов в сторонние сервисы еще больше.

[@sergeymironov7315]

Я верно понял по результатам тестов, что, прежде, чем выбирать между асинхронным и синхронным фреймворком, надо потестить максимальное время запроса к БД и уже от него отталкиваться?

[@t0digital]

Да в целом плюс-минус любое веб-приложение много ходит в БД и асинхронный фреймворк будет эффективнее

[@sergeymironov7315]

@@t0digital Допвопрос - а если asyncio.sleep присутствует в коде функции, это относится к io или нет? То есть, влияет ли время ожидания между запросами на выбор между синк и асинк?

[@t0digital]

asyncio.sleep отдает управление в цикл событий, но тут нет io операций, она просто «эмулируется», если можно так сказать. Если интересно с asyncio хорошо разобраться - почитай книгу «Asyncio и конкурентное программирование», Мэттью Фаулер. Мы читали в нашем книжном клубе Ботаним её, там осталось 3ч моих комментов по ней - t.me/t0digital/599

[@vovergg]

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

[@alexjuly7097]

А почему про вычисления сразу мультипроцессинг, а как же треды+нумпай, например.

[@garrygaller2853]

Треды в Python не мультиядерные. Процессы - мультиядерные. Так что использование numpy с тредами вряд ли ее ускорит (даже с учетом того, что там GIL может отпускаться) Даже тот же sklearn для ускорения алгоритмов ML использует joblib со включенной по умолчанию мультипроцессностью.

[@alexjuly7097]

@@garrygaller2853 есть пруф, что треды не "мультиядерные"? Я, честно говоря, про такое первый раз слышу.

[@garrygaller2853]

@@alexjuly7097 Не мультиядерные в том смысле, что только один поток программы может исполняться одновременно интерпретатором Python. Причина называется GIL (GIL есть также в Ruby; большая часть прочих скриптовых языки вообще однопоточные изначально). docs.python.org/3/glossary.html#term-global-interpreter-lock Так что многопоточность в скриптовых языках мало способствует параллелизму кода. Выгода есть только для IO задач, где потоки будут одновременно ожидать данных.

[@alexjuly7097]

@@garrygaller2853 так вы же сами сказали, что numpy отпустит GIL и вот параллелизм.

[@garrygaller2853]

@@alexjuly7097 Да. Но вот что написано в scipy cookbook в разделе Parallel Programming: "Учитывая описанные выше ограничения, возможно, не стоит тщательно переписывать код в многопоточной архитектуре. Но иногда, если вы можете сделать многопоточность с небольшим усилием, в этих случаях это может стоить того. ...Один из способов преодоления ограничений Gil, рассмотренных выше, заключается в использовании нескольких полных процессов вместо потоков. Каждый процесс имеет свой собственный GIL, поэтому они не блокируют друг друга так же, как это делают потоки." И нужно же учитывать, что 1) GIL будет отпущен не везде (а где именно нужно ковырять исходный код библиотеки, чтобы точно знать) 2) потоки это всегда общая память и нужно как-то синхронизировать доступ к данным, чтобы избежать гонок. А синхронизация это всегда блокировки. А блокировки это всегда тормоз кода.

[@trankov]

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

[@yahton309]

Однако из теории следует что ∀task speed(async_release(task)) >= speed(sync_release(task)), но это явно не всегда правда - реализация асинхронности хромает.

[@alexgladkov7996]

Спасибо

[@artemhrytsenko1353]

Я где-то читал, что есть практика делать несколько потоков, внутри которых работают асинхронные задачи. Насколько это эффективно?

[@t0digital]

если мы про питон, то несколько процессов, и внутри асинхронный код, тк многопоточность в питоне отстой (GIL)

[@РоманИгнатов-ж8с]

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

[@samatzhussipov1139]

ваш мак 2015 года ?

[@t0digital]

да

[@Kirill-rg8vj]

А можно просто сделать один монолит на джанге и несколько микросервисов на go

[@t0digital]

Можно, но если основная команда питонисты, то потом эти микросервисы на go могут стать проблемой, их надо поддерживать, а кто Go знает уже уволился, это проблема

[@Kirill-rg8vj]

Диджитализируй! Ну на самом деле не сильная проблема написать что-то на го ибо языки схожи, и те же авито говорят , что их питонисты за неделю осваивают го

[@t0digital]

Да ну прям за неделю, прям осваивают, не уверен. Отличий от питона там много, питон гораздо меньше имхо имеет общего с Go, чем со своими скриптовыми собратьями

[@vadimalekseev3621]

Может кто-нибудь показать/рассказать как выглядят системные вызовы? Например, в Clang в unistd.h есть функция fork, но как она сообщает ОС, что от неё требуется? Или, например, в go есть куча системных вызовов, вокруг которых построены обертки, но как оно внутри работает? Как сделай кастомный системный вызов без оберток?

[@victorklimov5254]

Как понимаю это интерфейс к ядру ОС. Те кто ОС проектируют этот интерфейс предоставляют. Как это на более низком уровне, чем на каком то ЯП написать хз.

[@PaulP738]

Давно думал: как можно организовать код на Джанге, используя чистую архитектуру?

[@googleadmin4749]

Красавчик

[@dasx100]

Хотел бы услышать мнение автора по поводу... Думаю взяться за изучения этого языка. Но все время останавливает одно. Есть ли смысл? (так как сам разработчик на js, не смотря на то что python тоже знаю - но практически с ним не работаю, итог знаю его намного хуже) И то что позволяет язык на том котором программирую по сути все то же что и python. И вот в чем собственно проблема (сам js вроде бы как бы и быстрее работает - прошу не закидывать помидорами )) - это как тесты те же говорят так и сам проводил (прошу не хейтить не js не phyton - хейтерам за скоростью - то вам асемблер нужен. та и как бы не распыляешься над языками фронт бэк) - и как бы решает задачи те же не плохо. Есть ли смысл начать изучать его - если уже с js нету не каких проблем? так как в видео вижу что вы не раз и его упоминали... Так как бывает что реально тот же python было бы использовать разумней - в место какого либо другого языка... Либо посоветовали бы продолжать с js развитие и стать хорошим спецом в одном деле? Да и спасибо за видео)

[@t0digital]

JS быстрее Python, это факт. Python из лидерской скриптовой тройки языков для веба (JS, PHP, Python) самый медленный. Но когда скорость сильно в приоритете, то выбор не падёт на скриптовые языки. Если не ощущаете желания изучить в дополнение Python и нет на то потребности - то не надо его изучать, конечно:) Но мозг программиста так устроен, что со временем ему всё равно хочется изучить-попробовать что-то новое, однажды желание изучить что-то новое станет настолько сильным, что что-то надо будет выбрать и тогда выбор может пасть на Python

[@dasx100]

​@@t0digital Большое спасибо за ваш ответ. Я то и не гоняюсь уже за скоростью. Вот в том и вопрос, что те же решения на python видел не раз что более понятные и более читаемые, та и как бы сами по себе намного проще чем на том же js в решении. На счет того же php немного не то - юзаю его для мелких целей, так как тот язык на котором работаю в основном - ну это как кусты бензопилой стричь против того же php - ну если не учитывать нюансы настройки самого сервера - что по сути к этому языку не какого отношения не имеет)) - но тут то про асинхронность... с php ну как бы не совсем то... Извиняюсь за коммент по скорости - хейтят языки за то что они мол хуже какого-то, что по сути бред) имел горький опыт. Что бы вы сами посоветовали бы - если есть уже опыт как и в других языках так и в phython - с чего бы старт дать?

[@cyberblogru]

Слушал обсуждение этого поста в подкасте Радио-Т (кстати, заметь). Они там не особо хвалили aiopg. Говорили, что asyncpg дал бы результаты лучше

[@t0digital]

Да, возможно, опять же надо тестить

[@АйдарХабиров-т3к]

Агонь.

[@t0digital]

спасибо