думаю, сейчас выяснится что там не блокировка loop'а, а просто open_connect иногда дольше обычного выполняется

Проявляется в том что корутины все выполняются раза в 2 дольше

Проявляется в том что корутины все выполняются раза в 2 дольше

раза в 2 дольше чем что?

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

Проявляется в том что корутины все выполняются раза в 2 дольше

все корутины, которые внутри себя делают reader.read?

можешь код показать?

Я предполагаю что read застревает в ожидании заполнения буфера

Нет, корутины выполняют запросы в базы данных через aiodbc

Обычно весь цикл опроса проходит секунд за 30-40

Но периодически занимает 80

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

Ну и это коррелирует с тормозами забикс сервера куда шлю результаты через open connection

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

там threadpool, насколько я помню

Да, пул потоков там

почти все aio*-либы для стораджей это обертки с threadpool'ом вокруг синхронных либ

Коррелирует очень явно

Ребята в чем разница npm-appium и python-appium-client, это просто разные клиенты?

Как сделать в питоне подобие структуры в шарпе?

Код приема смогу кинуть через 10 минут, отошёл на обед)

Может есть какая то аналогия?

Ребята в чем разница npm-appium и python-appium-client, это просто разные клиенты?

в том что npm-appium - пакет для node.js?

да кто-то не мог настроить uwsgi через юникс сокет. А потом кто-то сказал что unix сокет бывает tcp и udp

уже настроил 😊😊

Может есть какая то аналогия?

namedtuple \ dataclass

Может есть какая то аналогия?

+просто class

уже настроил 😊😊

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

в том что npm-appium - пакет для node.js?

Хм, установка у npm-appium значительное время занимает в отличии от python-appium-client вот и интересуюсь, первый почти час занял и не установился еще, а второй меньше минуты занял.

Нода она такая

бессмысленная и беспощадная

а питоновский клиент мог попросить компилятор =D

уже настроил 😊😊

через unixsocket?

asyn def recv_data(reader,size): data = b'' while len(data) < size: chunk = await reader.read(size-len(data)) if not chunk: return b'' data += chunk return data

вот так читаю

собственно если дольше обычного происходит open_connect или чтение - оно не должно аффектить на другие корутины в лупе же.

ну да

через unixsocket?

у которого внутри tcp

у которого внутри tcp

голый

бля ну не начинайте снова

=D

собственно если дольше обычного происходит open_connect или чтение - оно не должно аффектить на другие корутины в лупе же.

не должно. Только те, которые делают await recv_data(...)

через unixsocket?

ага

ага

а зачем так?

а зачем так?

в мануалах которые я читал, так написано)

окей

я думал было осмысленное решение

я думал было осмысленное решение

есть же поверье, что юникс сокеты работают быстрее

я думал было осмысленное решение

я не настолько крут в линуксе чтоб принимать таие решения 😁

бессмысленная и беспощадная

Спасибо за ответ, мучился с гуглом.

есть же поверье, что юникс сокеты работают быстрее

да я даже склонен согласиться с ним

есть же поверье, что юникс сокеты работают быстрее

так и было написано)

только это не говорит что надо так делать

есть же поверье, что юникс сокеты работают быстрее

А они не работают?

А они не работают?

работают

это просто отсылка к дискуссии выше

те полпроцента выигрыша ничто по сравнению с невозможностью горизонтально масштабироваться

те полпроцента выигрыша ничто по сравнению с невозможностью горизонтально масштабироваться

ну + еще управление доступом при помощи fs permissions.

что иногда может быть таки нужно

те полпроцента выигрыша ничто по сравнению с невозможностью горизонтально масштабироваться

до 30% разница же доходит

те полпроцента выигрыша ничто по сравнению с невозможностью горизонтально масштабироваться

это может иметь смысл если, например, в одном контейнере nginx и uwsgi

масштабированию это не помешает

до 30% разница же доходит

Да? На каких пакетах?

Да? На каких пакетах?

Частая установка новых подключений допустим

масштабированию это не помешает

Помешает, nginx становится не один

Частая установка новых подключений допустим

А. Так nginx вроде держит соединение

ну + еще управление доступом при помощи fs permissions.

и возможность не парится с пересечением портов, всё по свои директориям, это может быть удобно

Помешает, nginx становится не один

ну да, кому-то может такое и нужно

угу

А. Так nginx вроде держит соединение

Ну не всегда можно использовать nginx и пул коннектов

Ну не всегда можно использовать nginx и пул коннектов

Ну мы про uwsgi все ещё говорим

Ну мы про uwsgi все ещё говорим

А, ну ладно

Глобально-то понятно

Я именно в разрезе задачи

ну да, кому-то может такое и нужно

Ну тогда становится не просто tcp, а tcp + unixsocket. Что явно не станет быстрее

Ну тогда становится не просто tcp, а tcp + unixsocket. Что явно не станет быстрее

Станет даже так) Не отправляются tcp подтверждения

Станет даже так) Не отправляются tcp подтверждения

Разве юникс сокет настолько быстрей?

Ну тогда становится не просто tcp, а tcp + unixsocket. Что явно не станет быстрее

Не станет. Я имел в виду, что если у тебя изначально по каким-то причинам внутри контейнера есть и nginx, и uwsgi. То между nginx'ом и uwsgi имеет смысл использовать unix socket вместо tcp-сокета

Не станет. Я имел в виду, что если у тебя изначально по каким-то причинам внутри контейнера есть и nginx, и uwsgi. То между nginx'ом и uwsgi имеет смысл использовать unix socket вместо tcp-сокета

Ну это вообще антипаттерн докера в один контейнер пихать. Но вообще да

Разве юникс сокет настолько быстрей?

Ну доли процента, как Тишка изначально сказал

Ну доли процента, как Тишка изначально сказал

В это я могу поверить)

Станет даже так) Не отправляются tcp подтверждения

Так tcp между нодами остаётся

Так tcp между нодами остаётся

Да, и к ним ещё добавляется tcp до wsgi

Да, и к ним ещё добавляется tcp до wsgi

Эм. Я про tcp vs tcp+unix, а не tcp+tcp