теоретически возможно все

А что тогда за тема со стримами rethinkdb?

но я не вижу смысла юзать 2 сервера если у меня в одном из 8 ядер юзается только одно на 90%)

но я не вижу смысла юзать 2 сервера если у меня в одном из 8 ядер юзается только одно на 90%)

дак речь не идет про физический сервер

А что тогда за тема со стримами rethinkdb?

а это немного другое. это поток в котором генерируется список изменений в таблице

дак речь не идет про физический сервер

даже виртуалки

но я не вижу смысла юзать 2 сервера если у меня в одном из 8 ядер юзается только одно на 90%)

Ну без разницы же, это два процесса на одном сервере или на разных

у меня вот есть виртуалка с 8 ядрами под это дело

да и даже про виртуалки

и через селери кстати нагрузка таки размазывается

А зачем тут гевент, можно же на асинке и веб, и сокеты

ну естественно

только работает оно как-то не совсем очевидно

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

Например, очередь сообщений

Например, очередь сообщений

ну celery + redis юзается

Я просто не знаю что такое стрим rethinkdb, поэтому и думал что это очередь

ну celery + redis юзается

Да не нужен тебе селери

только работает оно как-то не совсем очевидно

возьми вместо целери асинхронный сокетио и запускай пул процессов - воркеров

по идее их сельдерей через редис внутри себя и связывает

Возьми просто очередь сообщегий

возьми вместо целери асинхронный сокетио и запускай пул процессов - воркеров

подскажи плз конкретную библиотеку

попробую от нее уже плясать

Я ж уже вчера говорил python-socketio

умеет в асинхронный режим

ну так flask_socketio тоже работает асинхронно

за счет gevent

за счет gevent

ну у тебя ж именно с ним и проблема да?

там под капотом все тот же python-socketio

я предлагаю взять asyncio

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

я предлагаю взять asyncio

Как это позволит ему заюзать несколько ядер?

Как это позволит ему заюзать несколько ядер?

заюзать процесс пул

у gevent действительно проблема с мультипроцессингом из-за агрессивного манкипатчинга

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

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

Так, а сколько у тебя клиентов?

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

под клиентом я имел ввиду подключение.

Чем мы вообще пытаемся cpu занять?

Рассылкой до клиентов?

Их там тысячи?

Чем мы вообще пытаемся cpu занять?

подключение через sdk, забирание данных, отправка сокетио-сообщения

скажем так, 13 стримов грузят ядро на 80%

вот от этого можно считать нагрузку

Эээ. 13 стримов?

А клиентов сколько?

Я не знаю что такое стрим

так

давайте не будем путаться

еще раз

И как у тебя спланк и rethinkdb смешались

Я так понял, спланк - это что-то типа хадупа?

есть "стрим" - это функция в которой запускается бесконечный цикл, каждая итерация опрашивает спланк, и отправляет сообщение по сокетио

Я так понял, спланк - это что-то типа хадупа?

что-то типа ELK

Ээ

ээээ

вот точно

и где тут у нас CPU bound

Ты уверен, что вообще те технологии используешь, которые нужны?

инахуа нам мультипроцессинг?

есть "стрим" - это функция в которой запускается бесконечный цикл, каждая итерация опрашивает спланк, и отправляет сообщение по сокетио

ты не пробовал несколько процессов фласка запустить?

13 стримов на сколько клиентов?

Ты уверен, что вообще те технологии используешь, которые нужны?

уверен

13 стримов на сколько клиентов?

зачем столько вопросов про неких клиентов?

стримы отдаются на одну вебморду

ERROR: S client not available

зачем столько вопросов про неких клиентов?

Потому что сокетио связан с клиентами.

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

А остальное - нет

Стримы - это что-то типа топиков в кафке?

и я все ещё не понимаю, откуда тут CPU-bound

на клиенте (то есть в браузере) дашборда с 13 окошками, каждое из которых ловит сообщение по сокетио в своем неймспейсе

Стримы - это что-то типа топиков в кафке?

возможно

т.е. клиент у нас 1

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

т.е. клиент у нас 1

ну допустим да, Одна страница с 13 компонентами, каждый из которых ловит сокетио по своему неймспейсу

есть "стрим" - это функция в которой запускается бесконечный цикл, каждая итерация опрашивает спланк, и отправляет сообщение по сокетио

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

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

так и есть

ну допустим да, Одна страница с 13 компонентами, каждый из которых ловит сокетио по своему неймспейсу

а cpu тут кто должен загрузить?

рецинк тут вообще для фронта больше

ок. то есть 1 клиент, 13 сокетио подключений., которые занимаются IO

итого, rethink db выкинули. Есть поллинг спланка

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

ок. то есть 1 клиент, 13 сокетио подключений., которые занимаются IO

да

итого, rethink db выкинули. Есть поллинг спланка

да

так

а CPU тут кто ест?

спланк?

или поллинг спланка?

так еще раз, что мешает запустить несколько инстансов фласка?

и разруливать сверху nginx \ gunicorn

а CPU тут кто ест?

спланк вообще на отдельном серваке, цпу на мой взгляд жрет поллинг + отправка сообщения по сокетио. Итерация ради теста сейчас занимает 1 секунду

ну будет 2-3

спланк вообще на отдельном серваке, цпу на мой взгляд жрет поллинг + отправка сообщения по сокетио. Итерация ради теста сейчас занимает 1 секунду

опрос спланка + отправка сообщения - 1 секунда?

я не совсем понимаю что ты собрался делать в мультипроцессинге. крутить бесконечные IO лупы?

опрос спланка + отправка сообщения - 1 секунда?

да. опрос происходит по конкретному поиску, уже запущенному там, и забирается json с 15 словарями в списке, по сути строки 3

а параллелить ты что тут собрался?