ON
Треды в питоне норм. если правильно применять
Size: a a a
2020 February 17
PП
dbapi
Причем тут dbapi?
ON
ну main поток с ioloop проседает на GIL, правильно?
тут ioloop вообще лишний, нужно делать обычный тредово синхронный сервис
YM
Причем тут dbapi?
может не так выразился, но к постгре сокет открывается, это IO
YM
Oleg N
тут ioloop вообще лишний, нужно делать обычный тредово синхронный сервис
лучше, но лучше выкинуть впизду алхимию
дешевле обойдется
дешевле обойдется
ON
лучше, но лучше выкинуть впизду алхимию
дешевле обойдется
дешевле обойдется
👍
PП
может не так выразился, но к постгре сокет открывается, это IO
Он открывается в блокирующем режиме, внутри питоноского треда, так и работает асинхронная обертка над алхимией
ON
а в каких случаях он может не давать никакого прироста?
вот сервис: чтение из rabbitmq, походы в postgres, redis
ответочка опять в rabbitmq direct-reply-to
вот сервис: чтение из rabbitmq, походы в postgres, redis
ответочка опять в rabbitmq direct-reply-to
Этот сервис производит синхронные или асинхронные вызовы (т.е. клиент ждёт ответа в блокирующием режиме)?
YM
Oleg N
Этот сервис производит синхронные или асинхронные вызовы (т.е. клиент ждёт ответа в блокирующием режиме)?
всё асинхронное (кроме стандартного логгера)
либо я чего-то не заметил, но хз, проверял я тщательно
все либы с приставкой
либо я чего-то не заметил, но хз, проверял я тщательно
все либы с приставкой
aioYM
Он открывается в блокирующем режиме, внутри питоноского треда, так и работает асинхронная обертка над алхимией
по тому случаю открываю его в другом процессе (не треде даже), где лупа нет
ON
всё асинхронное (кроме стандартного логгера)
либо я чего-то не заметил, но хз, проверял я тщательно
все либы с приставкой
либо я чего-то не заметил, но хз, проверял я тщательно
все либы с приставкой
aioНе я не про это, как я понял это некий сервис который по-сути RPC, дак вот когда клиент делает вызов/задачу в этот сервис, он ждёт ответ от сервиса?
PП
по тому случаю открываю его в другом процессе (не треде даже), где лупа нет
У вас там готовая асинхронная обертка или сами как-то делаете?
YM
Oleg N
Не я не про это, как я понял это некий сервис который по-сути RPC, дак вот когда клиент делает вызов/задачу в этот сервис, он ждёт ответ от сервиса?
да, 50% методов клиент ждет ответа (via rabbitmq direct-reply-to)
YM
У вас там готовая асинхронная обертка или сами как-то делаете?
сами, всё под контролем поэтому
ON
да, 50% методов клиент ждет ответа (via rabbitmq direct-reply-to)
А что происходит если сервис подвис/упал, а клиенты накидали задач?
Или если клиент сделал вызов, но ушел по таймауту?
Или если клиент сделал вызов, но ушел по таймауту?
YM
Oleg N
А что происходит если сервис подвис/упал, а клиенты накидали задач?
Или если клиент сделал вызов, но ушел по таймауту?
Или если клиент сделал вызов, но ушел по таймауту?
на всё тайм-ауты
сервис не кушает более чем надо (рулится засчет rabbitqm.channel.qos + количество корутин-воркеров)
если где затык - растет очередь
если клиент ушел - тут пофиг, запрос отрабатывается и рэббит его в /dev/null спихнет, условно
сервис не кушает более чем надо (рулится засчет rabbitqm.channel.qos + количество корутин-воркеров)
если где затык - растет очередь
если клиент ушел - тут пофиг, запрос отрабатывается и рэббит его в /dev/null спихнет, условно
ON
на всё тайм-ауты
сервис не кушает более чем надо (рулится засчет rabbitqm.channel.qos + количество корутин-воркеров)
если где затык - растет очередь
если клиент ушел - тут пофиг, запрос отрабатывается и рэббит его в /dev/null спихнет, условно
сервис не кушает более чем надо (рулится засчет rabbitqm.channel.qos + количество корутин-воркеров)
если где затык - растет очередь
если клиент ушел - тут пофиг, запрос отрабатывается и рэббит его в /dev/null спихнет, условно
Отработанный запрос (результат) должен в ответном канале повиснуть, а не в дев-нулл
ON
Oleg N
Отработанный запрос (результат) должен в ответном канале повиснуть, а не в дев-нулл
А если ответный канал закрывается, чтобы не хранить эти результаты, то производительность сего решения будет ниже плинтуса, около 50 вызовов в сек.
ON
Я использую "inverted json" вместо реббита, чтобы не было этих повисших сообщений на входе и выходе, + работает более чем в 7 раз быстрее реббита 😉
YM
Oleg N
Отработанный запрос (результат) должен в ответном канале повиснуть, а не в дев-нулл
сдается мне, что publish в default-exchange с параметром reply-to как-то эту ситуацию обрабатывает
судя по доке этот экстеншн не дает никаких гарантий, либо доставлено сразу - либо нахуй
судя по доке этот экстеншн не дает никаких гарантий, либо доставлено сразу - либо нахуй