постгре позволяет сразу файл грузить

Привет!

Ребят, такой вопрос – насколько плохо делать вот так:

Task.start_link(fn -> ViewerPresence.log_subscribe(subscription_id) end)

ViewerPresence.log_subscribe это просто INSERT в БД.

Таск вызывается на коннект к каналу в Фениксе, то есть в определенные моменты это может быть довольно часто происходить, но вряд ли чаще 300-500 раз в минуту

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

мне нужна одна запись на один ивент

это не каунтер

Нужен ли мне здесь какой-то менеджер процессов чтобы не спавнить процессов больше, чем Х?

и чем этот Х может быть обусловлен? (То есть что крутить в настройках)

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

Вы можете сделать пул на 500 процессов, если знаете что чаще всего их меньше 500. Сама цифра зависит наверное от того, сколько запросов к базе она может переварить

Я как бы понимаю, что можно, мне интересно понять, нужно ли.

Если у вас постоянно по 500 запросов, А вы сделаете пул на 100, то очевидно что это не буду работать. Если у вас обычно 100, а иногда 500, и вы сделаете на 150, то сообщения рано или поздно будут разгребаться

Понял. С этим наверное не подскажу.

Ну да, мне скорее тут интересны фейл истории, типа не ограничивали и случилось то-то. В принципе, могу и сам дождаться, но если есть вот прям какие-то приниципы, то был бы рад сразу соломку подстелить.

Я танцую от того, что у Экто должен быть пул коннектов к БД, и по идее они просто в очередь должны выстроиться, и все

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

а мне вот интересно имеет ли смысл воркеров из пула отправлять в hibernate после того как они отработали

если их всего 500, то это экономия на спичках,
да и здесь задача не для
пула воркеров, а для
ограничителя лимита,
типа jobs или safetyvalve

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

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

ну или у вас embedded балалайка с жестокими ограничениями

инсерты в базу лучше последовательно делать и, желательно пачками. Но в вашем случае это сильно преждевременная оптимизация. Т.к. при инсерте пачками производительность MySQL вырастает примерно так:
40,000 → 247,000 inserts / second on localhost
12,000 → 201,000 inserts / second over the network
Процессы спавнить все равно нужно, если нужно запускать асинхронно. Благо они легковесные и в вашем случае короткоживущие, так что проблем быть не должно.