И сколько ядер работает ?

И сколько ядер работает ?

одно, а какая разница, если задача i/o bound?

если мне надо будет больше - сделаю run_in_executor

Запущу пока в контейнерах

о_О

http://telegra.ph/Kotiki-Kodyat-vypusk-5-07-23

Девопсы, у нас уже 5 выпуск вышел

в следующем хотим поговорить о контейнерах

В питоне Гил на IO операциях отпускается

Можно корутины на asyncio заюзать, если треды не нравятся

На IO-операциях на тредах все доступные будут

И сколько ядер работает ?

Кнопка reply лучше чем forward :)

одно, а какая разница, если задача i/o bound?

Это точно

Можно корутины на asyncio заюзать, если треды не нравятся

треды с корутинами не связаны

по крайней мере, в питоне :) в го и эрланге там чуть сложнее

треды с корутинами не связаны

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

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

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

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

но при этом несколько тредов в которых корутины будут еще веселее )

Быстрый - быстрее, чем просто последовательные синхронные сетевые запросы

Быстрый - быстрее, чем просто последовательные синхронные сетевые запросы

если у тебя сокет в синхронном режиме открыт - то у тебя и будут синхронные сетевые запросы

независимо от того, треды у тебя или нет

HTTP-клиент типа requests и нижележащий urllib на каждый коннекшен не открывают новый сокет разве?

или мы про собственноручно написанный TCP-клиент говорим?

Давайте про обычный SSH

Нужно открыть 10 одновременных сессий, считать вывод на 10000 строк и распарсить

Нужно открыть 10 одновременных сессий, считать вывод на 10000 строк и распарсить

seq 1 10 | xargs -P0 sh -c 'ssh host sh -c "run_command_with_10000_lines_output"' | smart_parser

:) Это равносильно субпроцессу в питоне. Но да, тут будет осевый форк

Нужно открыть 10 одновременных сессий, считать вывод на 10000 строк и распарсить

asyncssh

давай чего посложнее

Посложнее в NSA

За либу спасибо! Пора на 3й переходит

За либу спасибо! Пора на 3й переходит

ты до сих пор не перешел? позор тебе

У меня ещё перла полно...

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

Wat?

Wat?

что непонятно?

За счёт чего это корутины будут быстрее ?

За счёт чего это корутины будут быстрее ?

за счет быстрой передачи контекста выполнения на i/o операциях

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

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

шта

нет

корутины работают в общем случае в одном треде

поэтому да, блокирующая операция блочит весь тред

И

но если их нет - то корутины будут быстрее гораздо, чем треды, ибо им не нужны примитивы синхронизации и прочие ожидания

за счет быстрой передачи контекста выполнения на i/o операциях

Не правда ж

Не правда ж

почитай про то, что такое кооперативная многозадачность и как она работает

а еще посмотри на любые тесты, где, скажем, сравниваются торнадо и фласк

торнадо держит раз в сто больше коннектов

почитай про то, что такое кооперативная многозадачность и как она работает

Бгг, ща приду с прогулки и поспорим

Бгг, ща приду с прогулки и поспорим

да тут и спорить не о чем, на самом деле

но ок

@Enchantner в общем я не понимаю, за счет чего корутины быстрее в передаче контекста? обычно нормальные люди прибивают операции по ченелу к 1 потоку. К примеру как в netty

@Enchantner насчет блокинга - если заблокировать тред, то тоже будет беда. А вот в случае корутин не факт. ведь шедулер может просто отдать квант времени другой корутине, но это зависит от реализации

Если CPU-bound задача залочит asuncio-корутину - скедъюлер ничего не сделает

@Enchantner насчет блокинга - если заблокировать тред, то тоже будет беда. А вот в случае корутин не факт. ведь шедулер может просто отдать квант времени другой корутине, но это зависит от реализации

Сейчас тоже до дома дойду - объясню. Вкратце - все ровно наоборот.

Народ, а подскажите где сейчас модно хранить конфигурацию энвов?

Для деплоя используется ansible

Для деплоя используется ansible

в git'e например, в любом key value хранилище, redis

Сейчас и храним в гите. Есть проблема в том, что есть еще один проект использующий эти же конфигурации, но только не для деплоя. Написан он в другом формате. В итоге получается дублирование

ERROR: S client not available

Есть ли резон использовать etcd, если конфигурации достаточно много?

я поднимал подобный вопрос

я вот гадаю почему так нельзя: ansible, факты хранит в redis я хочу сделать новый факт, и что бы он сохранился в redis но set_fact работает не пропихивает факты в редис, а работает в контексте инстанса ansible и пропадает после окончание плейбуки

теперь смотрю в сторону salt'a

А если использовать только в к-ве чтения? Мне не нужен механизм пропихивания через set_fact

в качестве чтения тоже вопрос инструментариями ansible и facts_cache (например тот же redis) нужно факты привязывать обязательно к какому-нибудь хосту, нелья взять и создать факты для environment'а - если только какой-то эфемерный хост и на него добавлять факты

Сейчас тоже до дома дойду - объясню. Вкратце - все ровно наоборот.

Я понимаю про что ты. Что в кооператившине будет совсем плохо. Но если у тебя будет пул потоков, то какбы блок там будет ничуть луше

Я понимаю про что ты. Что в кооператившине будет совсем плохо. Но если у тебя будет пул потоков, то какбы блок там будет ничуть луше

Блок в одном потоке никак не влияет на остальные - раз. Корутины передают управление согласно неблокирующей логике приложения, а не ждут системного шедулера - два

В итоге внешние события запускают твой код, но не тормозят его

Блок в одном потоке никак не влияет на остальные - раз. Корутины передают управление согласно неблокирующей логике приложения, а не ждут системного шедулера - два

Это то дело понятно, но в пуле потоков блокинг впринципе таже самая проблема

Это то дело понятно, но в пуле потоков блокинг впринципе таже самая проблема

Если ты пытаешься все потоки в пуле синхронизировать - да, разумеется. Но это надо далеко не всегда

И потом, код в потоках все равно параллельно выполняется

ок, я понял твою мысле

вернемся к другой, за счет чего корутины будут быстрее?)

вернемся к другой, за счет чего корутины будут быстрее?)

Я не говорил, что они всегда будут быстрее. Я говорил, что они будут быстрее на i/o bound задачах, когда вместо тяжёлой синхронизации тяжёлых тредов достаточно будет ожидать событий от системы на сокете

не совсем понял про какую синхронизацию идет речь

обычно делается несколько тредов, которые делают epoll и в случае если ивенты есть их разгребают воркеры

каналы привязаны к этим воркерам

ну и соотсветственно контекст канала всегда в одном потоке

не совсем понял про какую синхронизацию идет речь

У тебя сокет одновременно будет принадлежать только одному треду, иначе в нем будет каша. Соответственно, синхронизация в виде мьютекса или критической секции будет необходима

в том то и дело, что сокет будет привязан к одному треду -> не нужен мьютекс

он всегда будет обработан одним потоком

обычно делается несколько тредов, которые делают epoll и в случае если ивенты есть их разгребают воркеры

Делая epoll из треда, ты делаешь руками эвентлуп и эмулируешь те же самые корутины

exactly

только в твоих руках полный контроль

и какбы твоя теория про "быстрее" рушится)

только в твоих руках полный контроль

шта

нет

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

это да, так