У меня не получилось себе настроить. Проведена оптика от ростелеком и использую их роутер. На него впн не установить. Посмотри настройки своего роутера, может в нем уже встроен впн. Если нет, то некоторые модели можно прошить на dd-wrt / openwrt с поддержкой VPN.
В общем у меня есть 50 запросов к API, из-за того что json файлы которые я получаю грузятся секунд 10+, в асинхроне по идее будет быстрее, я как раз сейчас хочу с декоратором замерить эту разницу. Пробовал сабпроцесс, всё подвисло слегка, может быть если разбить по 10 процессов будет лучше. Просто в моей задаче каждая секунда свежих данных это большое преимущество.
В общем без: 580 секунд с asyncio: 68 секунд может есть варианты как можно и лучше реализовать задачу + я не проверял 100% целостность сохранённых данных, но для такого рода скрипта прирост производительности хороший
т.е. если задача требует асинхронный phyton то наверное её нужно писать не на phyton? ну или тот кусок который выставляет такие требования стоит написать на чём то другом и подружить с остальной программой?
Можно писать на синхронном питоне. Для повышения производительности запустить больше процессов. Сильно от задачи зависит. Надо конкретный пример рассматривать.
@@kuliev.vitaly а что посоветуешь к изучению, если речь НЕ идет о производительности - Flask или FastAPI? 2-й вариант привлекает наличием не столько асинка, сколько тайпинга, валидации (пайдантик) и т.д., но насколько он уступает Фласку по востребованности на рынке?
@@stshib6627 Flask и Django - это история про "относительно" небольшие продукты (они могут быть высоконагруженными, но не размазаны на большое количество сервисов). Например, твоя команда пилит сайт\приложение и в нем десяток микросервисов (аутентификация, склад, корзина и т.д.). Где-то надо фронты подпилить, где-то какие-то формы хитрые реализовать и т.д. Aiohttp и FastAPI - это тема про чистый бэкенд, где ты фронтов не то что не видишь, ты даже понятия не имеешь как они выглядят. Тут твоя команда пилит сервис, например, который считает кредитный рейтинг заемщика на основе данных, которые тебе прислал другой сервис, который в свою очередь собрал их из фотки с телефона, данных с кредитного бюро, всяких черных списков и т.д. А эти данные производят другие сервисы, которые ходят в третьи сервисы и т.д. Т.е. большая распределенная система, которая работает на то, чтобы клиент в приложении в итоге увидел "одобрено" или "отклонено". Для примера, в яндекс.такси на 2021 год было 800 микросервисов. Учитывая, что и фласк и джанго за последние пару лет начали внедрять асинхронщину - это в любом случае востребованная история
автору спасибо! дальше я не автору, а вообще, мало ли кто не занает этого.)) мультипроцессинг это не про ядра! это про экземпляры программы! а будут ли они выполнены параллельно на ядрах, ни кто не знает.😁 точнее ОС знает.🤣 мультипроцесинг весит не слабо под задачи ожиданий, лучше генераторы использовать или asyncio. asyncio очень опасен! чуть где ошиблись, им самая быстрая рука за западе вас поимеет в раз.🤣 купит 10 видеокарт 4090 у вас по 1$, или 100шт. и сразу помете что такое асинхронность.🤣 и помните самое главное! Python медленный только при первом запуске!!! поверьте, это очень важно знать и понимать!
Я не согласен, что multithreading и multiprocessing выигрывают. Как по мне, их сложнее дебажить (особенно multiprocessing) и в обоих случаях мы не управляем планированием потоков и зависим от ос. А с multiprocessing ещё и проблема ipc встаёт для обмена данными между процессами. Возможно в питоне есть решение из коробки, но multiprocessing ни разу не использовал, поэтому не знаю. И от сюда вторая проблема. По-моему опыту рынок уже порешал и большинство людей лучше знают асинхронность, поскольку это всё чаще применяется в проектах и чаще спрашивают на собесах. Причём вопросы про асинхронность могут быть довольно глубокие, а про трэды и процессов обычно просят своими словами общее понимание изложить. Следовательно и бизнесу проще найти асинхронного программиста даже исходя из того, что кандидат скорее асинхронность в себя вдалбливал при подготовке к собесу чем потоки и трэды.
Справедливости ради я в основном про backend собеседования. На ds позиции возможно действительно больше мультипроцессинга. Мне всегда казалось, что на проде мультипроцессинга почти нет. Если надо параллелить на cpu, то в прод обычно сишный extension тащат имхо.
На питоне обычно распараллеливают через multiprocessing. Сишный код обычно пишут для ускорения алгоритма. Множество питоновских библиотек написано на си/си++, но у меня нет такого опыта.
Дослушал до 20% прироста производительности от асинхронщины и не смог дальше смотреть. Дядь, откуда вы все берете сложность асинхронщины? Каждый раз этому удивляюсь. Пишу микрачи на aiohttp и fastapi и ниразу не встречал проблем. Там где ждешь какое-то i/o - втыкаешь await - вот и вся асинхронщина. Если по мудацки код написан и не понятно, где и чо ждем - это да, это проблема, но это проблема мудацкого кода, она и в синхронных решениях такая же. На счет мультипроцессинга - согласен, есть свои плюсы, но они сжираются оверхедом на запуск процессов и решение железных проблем (тупо нужно сильно больше ресурсов, чтобы обрабатывать тот же объем запросов). Ну и в некоторых случаях вылазят race condition и прочие приколы одновременного доступа. Самый очевидный и простой путь - асинхронный сервис, в котором тяжелые cpu задачи вынесены в ProcessPoolExecutor (который запущен при старте сервиса, т.е. по сути крутится постоянно).
> Дядь, откуда вы все берете сложность асинхронщины? Сложность чтения кода, неочевидность изменения переменных из разных нитей исполнения, проблемы с поиском программистов... Возможно, для тебя этот код не будет сложным, но он явно сложнее чем одна синхронная функция.
> На счет мультипроцессинга - согласен, есть свои плюсы, но они сжираются оверхедом на запуск процессов и решение железных проблем (тупо нужно сильно больше ресурсов, чтобы обрабатывать тот же объем запросов). Насколько больше нужно ресурсов? В деньгах. По моему опыту экономия выходит порядка нескольких долларов, чем на фоне зарплат разработчиков можно пренебречь.
Вы конечно интересно все обрисовали, но ваши тезисы удивительно плохо пересекаются с реальностью. 1. Если мидл разработчик на Python не умеет в асинхронность - он не мидл. Если джун не умеет он такой себе джун, можно взять только если очень дешевый. Асинхронность поддерживается Python нативно, а это значит умение работать с асинхронным кодом не является опциональным знанием - это обязательное знание. 2. Оценка сложности и поддерживаемости очень условная, так как добавить асихронный вызов в легаси код переписав при этом пару функций задачка на час времени. Написать при этом пул воркеров и распаралелить на несколкьо процессов с возвратом результата через какой нибудь пайп кажется ничуть не проще(а скорее всего потребует больше вмешательств и значит сложнее). 3. В проектах не касающихся МЛ 90% задач это И/О в связи с этим использование асинхронного подхода вместо синхронного ускоряет процессы не на проценты, а на порядки. Когда вам нужно сделать 10000 запросов в другие сервисы каждый из которых занимает хотя бы 1 секунду у вас один вариант это использовать асинхронные вызовы. С ответам в случае веб сервера такая же история. 10 сессий к базе ? Ограничение? Не знаю что вы использовали, но вы либо не ознакомились с документацией(приняв дефолтное значение за ограничение), либо использвоали что то странное. В реальных высоко нагруженных проектах будут сотни подключений. Распределенная микросервисная архитектура реально большого проекта, а не сайта маленькой компании - это тысячи запросов между сервисами, сотни одновременно выполняющихся задач. И только грамотное использование ВСЕХ возможностей языка позволит вам решать действительно сложные задачи в больших проектах. Не надо забивать гвозди микроскопом.
Ты все верно говоришь, но мой опыт говорит об обратном. Да можно переписать с учетом асинхронности и это будет оптимально с точки зрения производительности. Типичный сервис потребляет несколько ядер и несколько гигов оперативки. Твои улучшения могут сэкономить до 10к рублей в месяц на инфраструктуре. При этом требуется поддерживать асинхронные библиотеки и КАЖДЫЙ разработчик в команде должен уметь и понимать это. Это неизбежно замедляет темпы разработки и требует большей квалификации от разработчиков. С точки зрения бизнеса намного выгоднее иметь оверхед по железу и при этом развиваться быстрее. Исключение - сервисы, где рыночная стоимость аренды серверов превышает 1млн рублей. Там оптимизации о которых ты говоришь будут иметь смысл. Тогда возникает вопрос к питону - более выгодно это будет переписать на GO или другом более быстром языке программирования и это точно будет быстрее всех оптимизаций на питоне, которые ты сделаешь. Питон ценят за быструю разработку и простоту.
"Нить - плохой термин и пересекается с переводом Tread, но более подходящего русского термина я не нашел." А как этот термин звучит на английском? И спасибо за видео!
Где в библиотере BeautifulSoup используется асинхронный код?
Не используется. Я привел пример бага в библиотеке.
Привет,когда видео по настройке впн на роутер ? ( интересует асус роутер)
У меня не получилось себе настроить. Проведена оптика от ростелеком и использую их роутер. На него впн не установить.
Посмотри настройки своего роутера, может в нем уже встроен впн. Если нет, то некоторые модели можно прошить на dd-wrt / openwrt с поддержкой VPN.
В общем у меня есть 50 запросов к API, из-за того что json файлы которые я получаю грузятся секунд 10+, в асинхроне по идее будет быстрее, я как раз сейчас хочу с декоратором замерить эту разницу. Пробовал сабпроцесс, всё подвисло слегка, может быть если разбить по 10 процессов будет лучше. Просто в моей задаче каждая секунда свежих данных это большое преимущество.
В общем
без: 580 секунд
с asyncio: 68 секунд
может есть варианты как можно и лучше реализовать задачу + я не проверял 100% целостность сохранённых данных, но для такого рода скрипта прирост производительности хороший
ну в целом может ещё другой язык надо ;)
попробуй через multiprocessing распараллелить
т.е. если задача требует асинхронный phyton то наверное её нужно писать не на phyton? ну или тот кусок который выставляет такие требования стоит написать на чём то другом и подружить с остальной программой?
Можно писать на синхронном питоне. Для повышения производительности запустить больше процессов. Сильно от задачи зависит. Надо конкретный пример рассматривать.
@@kuliev.vitaly а что посоветуешь к изучению, если речь НЕ идет о производительности - Flask или FastAPI? 2-й вариант привлекает наличием не столько асинка, сколько тайпинга, валидации (пайдантик) и т.д., но насколько он уступает Фласку по востребованности на рынке?
По google trends Flask значительно популярнее, особенно в мире. Библиотек с подобным функционалом несколько десятков.
Я не думаю что в других языках асинхронная модель сильно отличается
@@stshib6627 Flask и Django - это история про "относительно" небольшие продукты (они могут быть высоконагруженными, но не размазаны на большое количество сервисов). Например, твоя команда пилит сайт\приложение и в нем десяток микросервисов (аутентификация, склад, корзина и т.д.). Где-то надо фронты подпилить, где-то какие-то формы хитрые реализовать и т.д.
Aiohttp и FastAPI - это тема про чистый бэкенд, где ты фронтов не то что не видишь, ты даже понятия не имеешь как они выглядят. Тут твоя команда пилит сервис, например, который считает кредитный рейтинг заемщика на основе данных, которые тебе прислал другой сервис, который в свою очередь собрал их из фотки с телефона, данных с кредитного бюро, всяких черных списков и т.д. А эти данные производят другие сервисы, которые ходят в третьи сервисы и т.д. Т.е. большая распределенная система, которая работает на то, чтобы клиент в приложении в итоге увидел "одобрено" или "отклонено". Для примера, в яндекс.такси на 2021 год было 800 микросервисов.
Учитывая, что и фласк и джанго за последние пару лет начали внедрять асинхронщину - это в любом случае востребованная история
автору спасибо! дальше я не автору, а вообще, мало ли кто не занает этого.))
мультипроцессинг это не про ядра! это про экземпляры программы! а будут ли они выполнены параллельно на ядрах, ни кто не знает.😁 точнее ОС знает.🤣
мультипроцесинг весит не слабо под задачи ожиданий, лучше генераторы использовать или asyncio.
asyncio очень опасен! чуть где ошиблись, им самая быстрая рука за западе вас поимеет в раз.🤣 купит 10 видеокарт 4090 у вас по 1$, или 100шт. и сразу помете что такое асинхронность.🤣
и помните самое главное! Python медленный только при первом запуске!!! поверьте, это очень важно знать и понимать!
Я не согласен, что multithreading и multiprocessing выигрывают. Как по мне, их сложнее дебажить (особенно multiprocessing) и в обоих случаях мы не управляем планированием потоков и зависим от ос. А с multiprocessing ещё и проблема ipc встаёт для обмена данными между процессами. Возможно в питоне есть решение из коробки, но multiprocessing ни разу не использовал, поэтому не знаю. И от сюда вторая проблема. По-моему опыту рынок уже порешал и большинство людей лучше знают асинхронность, поскольку это всё чаще применяется в проектах и чаще спрашивают на собесах. Причём вопросы про асинхронность могут быть довольно глубокие, а про трэды и процессов обычно просят своими словами общее понимание изложить. Следовательно и бизнесу проще найти асинхронного программиста даже исходя из того, что кандидат скорее асинхронность в себя вдалбливал при подготовке к собесу чем потоки и трэды.
По моему опыту чаще всего multiprocessing спрашивают на собеседованиях. IPC из коробки есть в стандартной библиотеке.
Справедливости ради я в основном про backend собеседования. На ds позиции возможно действительно больше мультипроцессинга. Мне всегда казалось, что на проде мультипроцессинга почти нет. Если надо параллелить на cpu, то в прод обычно сишный extension тащат имхо.
На питоне обычно распараллеливают через multiprocessing. Сишный код обычно пишут для ускорения алгоритма. Множество питоновских библиотек написано на си/си++, но у меня нет такого опыта.
Дослушал до 20% прироста производительности от асинхронщины и не смог дальше смотреть. Дядь, откуда вы все берете сложность асинхронщины? Каждый раз этому удивляюсь. Пишу микрачи на aiohttp и fastapi и ниразу не встречал проблем. Там где ждешь какое-то i/o - втыкаешь await - вот и вся асинхронщина.
Если по мудацки код написан и не понятно, где и чо ждем - это да, это проблема, но это проблема мудацкого кода, она и в синхронных решениях такая же.
На счет мультипроцессинга - согласен, есть свои плюсы, но они сжираются оверхедом на запуск процессов и решение железных проблем (тупо нужно сильно больше ресурсов, чтобы обрабатывать тот же объем запросов). Ну и в некоторых случаях вылазят race condition и прочие приколы одновременного доступа.
Самый очевидный и простой путь - асинхронный сервис, в котором тяжелые cpu задачи вынесены в ProcessPoolExecutor (который запущен при старте сервиса, т.е. по сути крутится постоянно).
> Дядь, откуда вы все берете сложность асинхронщины?
Сложность чтения кода, неочевидность изменения переменных из разных нитей исполнения, проблемы с поиском программистов...
Возможно, для тебя этот код не будет сложным, но он явно сложнее чем одна синхронная функция.
> На счет мультипроцессинга - согласен, есть свои плюсы, но они сжираются оверхедом на запуск процессов и решение железных проблем (тупо нужно сильно больше ресурсов, чтобы обрабатывать тот же объем запросов).
Насколько больше нужно ресурсов? В деньгах. По моему опыту экономия выходит порядка нескольких долларов, чем на фоне зарплат разработчиков можно пренебречь.
Вы конечно интересно все обрисовали, но ваши тезисы удивительно плохо пересекаются с реальностью.
1. Если мидл разработчик на Python не умеет в асинхронность - он не мидл. Если джун не умеет он такой себе джун, можно взять только если очень дешевый. Асинхронность поддерживается Python нативно, а это значит умение работать с асинхронным кодом не является опциональным знанием - это обязательное знание.
2. Оценка сложности и поддерживаемости очень условная, так как добавить асихронный вызов в легаси код переписав при этом пару функций задачка на час времени. Написать при этом пул воркеров и распаралелить на несколкьо процессов с возвратом результата через какой нибудь пайп кажется ничуть не проще(а скорее всего потребует больше вмешательств и значит сложнее).
3. В проектах не касающихся МЛ 90% задач это И/О в связи с этим использование асинхронного подхода вместо синхронного ускоряет процессы не на проценты, а на порядки. Когда вам нужно сделать 10000 запросов в другие сервисы каждый из которых занимает хотя бы 1 секунду у вас один вариант это использовать асинхронные вызовы. С ответам в случае веб сервера такая же история.
10 сессий к базе ? Ограничение? Не знаю что вы использовали, но вы либо не ознакомились с документацией(приняв дефолтное значение за ограничение), либо использвоали что то странное. В реальных высоко нагруженных проектах будут сотни подключений.
Распределенная микросервисная архитектура реально большого проекта, а не сайта маленькой компании - это тысячи запросов между сервисами, сотни одновременно выполняющихся задач. И только грамотное использование ВСЕХ возможностей языка позволит вам решать действительно сложные задачи в больших проектах. Не надо забивать гвозди микроскопом.
Ты все верно говоришь, но мой опыт говорит об обратном. Да можно переписать с учетом асинхронности и это будет оптимально с точки зрения производительности. Типичный сервис потребляет несколько ядер и несколько гигов оперативки. Твои улучшения могут сэкономить до 10к рублей в месяц на инфраструктуре.
При этом требуется поддерживать асинхронные библиотеки и КАЖДЫЙ разработчик в команде должен уметь и понимать это. Это неизбежно замедляет темпы разработки и требует большей квалификации от разработчиков. С точки зрения бизнеса намного выгоднее иметь оверхед по железу и при этом развиваться быстрее.
Исключение - сервисы, где рыночная стоимость аренды серверов превышает 1млн рублей. Там оптимизации о которых ты говоришь будут иметь смысл. Тогда возникает вопрос к питону - более выгодно это будет переписать на GO или другом более быстром языке программирования и это точно будет быстрее всех оптимизаций на питоне, которые ты сделаешь. Питон ценят за быструю разработку и простоту.
"Нить - плохой термин и пересекается с переводом Tread, но более подходящего русского термина я не нашел." А как этот термин звучит на английском? И спасибо за видео!
Это ли не Fiber имелся ввиду?