Классно объясняете! Кстати вместо res.headers.get('Content-Type').split('/')[1] можно использовать res.getheader('Content-Type').split('/')[1] Ещё ответы сервера могут повторяться, т.к. возвращаются просто рандомные картинки, поэтому можно проверять хэш каждой новой картинки в множестве и если его там ещё нет, то добавить в само множество и скачать, иначе проигнорить. Но для этого нужно будет сделать цикл while.
Много непонятно Если мы возьмем отдельно asyncio, проверим, отдельно asyncfiles итп, и сравним с мультитредингом? будет ли у нас прирост х4 или будет х3.99?
Спасибо! Если парсить асинхронно, то часто натыкаешься на блокировки со стороны сервиса(оно и понятно). Можете посоветовать best practices того, как нужно "замедлять" скрипт ? Это как то эмпирически определяется? ))
Привет! Ну например можно не 100 задач запускать, а 10(по 10)... Есть такая штука как очередь (pipe), задачки ставятся в очередь и на них подписываются воркеры (исполнители). Можно количеством воркеров ограеичить... Ну и старый добрый синхронный sleep никто не отменял....
сам отвечаю если использовать await download_a_cat(session, cat), то не будет параллельности скачивании картинок await - это дождаться и соответственно, при каждой итерации будет интерпритатор будет дожидаться скачивания картинки
gather закинет все таски в эвеетлуп и они начнуть выполняться "одновременно". For будет выполнять из последовательно и даже если там await (отпустить контроль и дать возмодность поработать кому-то еще), этого кого-то еще еще нет. Он появится на следующей итерации цикла...
В реальном проекте у меня на фронте картинка обрезается js функцией в браузере, потом попадает во view джанго приложения, происходит валидация и отправка в амазон корзинку. Пока не пробовала сравнить скорость работы, если функц-л обрезания картинки реализовать асинхронно во view джанго приложения. не могли бы в посоветовать, стоит ли отдавать предпочтение этому подходу? Особенно, если в проекте предусмотрена возможность загрузки нескольких картинок от клиента. Спасибо заранее.
Обрезание картинки звучит как "cpu-intensive" task... Для такого асинхронный способ не подходит... Если только этот функционал не реализован где-то в сети.... Если массово резать картинки надо или по процессам разбрасывать задачи или по воркерам (как в селери)
Классно объясняете!
Кстати вместо res.headers.get('Content-Type').split('/')[1] можно использовать
res.getheader('Content-Type').split('/')[1]
Ещё ответы сервера могут повторяться, т.к. возвращаются просто рандомные картинки, поэтому можно проверять хэш каждой новой картинки в множестве и если его там ещё нет, то добавить в само множество и скачать, иначе проигнорить. Но для этого нужно будет сделать цикл while.
Круто! Спасибо за видео, асинхронные коты просто лучшие
Спасибо!
Как и всегда - информативно и полезно!
Много непонятно
Если мы возьмем отдельно asyncio, проверим, отдельно asyncfiles итп, и сравним с мультитредингом? будет ли у нас прирост х4 или будет х3.99?
Еще не понятно, в случае asyncio у нас реально сколько файлов загружается в один момент? все 100?
Спасибо! Если парсить асинхронно, то часто натыкаешься на блокировки со стороны сервиса(оно и понятно). Можете посоветовать best practices того, как нужно "замедлять" скрипт ? Это как то эмпирически определяется? ))
Привет!
Ну например можно не 100 задач запускать, а 10(по 10)...
Есть такая штука как очередь (pipe), задачки ставятся в очередь и на них подписываются воркеры (исполнители). Можно количеством воркеров ограеичить...
Ну и старый добрый синхронный sleep никто не отменял....
была бы разница?
если вместо создание задач и использования gather, написать цикл который просто делает await download_a_cat(...)
сам отвечаю
если использовать await download_a_cat(session, cat), то не будет параллельности скачивании картинок
await - это дождаться и соответственно, при каждой итерации будет интерпритатор будет дожидаться скачивания картинки
gather закинет все таски в эвеетлуп и они начнуть выполняться "одновременно".
For будет выполнять из последовательно и даже если там await (отпустить контроль и дать возмодность поработать кому-то еще), этого кого-то еще еще нет.
Он появится на следующей итерации цикла...
Ну и лайк, подписка, репост...
@@cyber-paddleспасибо, готово.
Что может быть лучше асинхронных котиков ?
Ни-че-го!!!
В реальном проекте у меня на фронте картинка обрезается js функцией в браузере, потом попадает во view джанго приложения, происходит валидация и отправка в амазон корзинку.
Пока не пробовала сравнить скорость работы, если функц-л обрезания картинки реализовать асинхронно во view джанго приложения. не могли бы в посоветовать, стоит ли отдавать предпочтение этому подходу? Особенно, если в проекте предусмотрена возможность загрузки нескольких картинок от клиента. Спасибо заранее.
Обрезание картинки звучит как "cpu-intensive" task...
Для такого асинхронный способ не подходит...
Если только этот функционал не реализован где-то в сети....
Если массово резать картинки надо или по процессам разбрасывать задачи или по воркерам (как в селери)
Thanks a lot
А если использовать не асинхронные контекстные менеджеры? и обычный request? Это ленивый вопрос. Я если сам попробую, то напишу)
Можно, просто блокернет исполнения и магия асинхронщины пропадет
@@cyber-paddle понял. а как обходит блокировку асинхронка?
@@cyber-paddle спасибо
@@citieslg await передает управлений в loop, а не дожидается выполнения
Ого