У меня тут назрела целая пачка вопросов к эрлангистам: - старичок

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

Я PR в poolboy отправлял с год назад, где как раз репортились метрики занятости воркеров как отношение времени чекаута к чекину. Насколько я знаю, PR до сих пор там висит и не шевелится.

ага, именно поэтому меня пугает последний коммит 2018. Там никто уже не смотрит в репозиторий и не видит PR

Значит, можно форкнуть. Работает-то он стабильно. PR все чеки прошел: https://github.com/devinus/poolboy/pull/141

Так его много кто использует из мейнстрима.

я бы посмотрел https://github.com/lpgauth/shackle , отдельно я его не использовал, но использовал cql клиента сделанного на нем. автор живой, контактный, совт используется в high-load проектах

ок, пасиб

аналогично, есть pooler для epgsql. напрямую не использовал, но epgsql работает авторов ты знаешь https://github.com/epgsql/pooler

Ну Сергея то да, знаю )

я бы использовал shackle просто из упрямства потому-что

Ух ты. Cassandra client enable.

да, CQL вполне работчий + нативный в отличии от ужаса на c++

> round-robin, random Для пулла соединений это плохая тема

worker pool от inaka

сильно лучше, чем залипший sticky

Но хуже чем checkout пул в пулбое

а в чём там суть? Получил воркер и подержи его какое-то время у себя?

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

во! оно! спасибо. 🙂

У этого подхода есть свои проблемы, когда распределённый пул или когда запросов очень много и все они маленькие (по времени исполнения) Но это всё равно не подходит к пулам соединений бд или http

Иногда оно бывает не консистентным. Странные вещи случаются.

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

ок, пасиб

Доказательства чего? Вот представь у тебя пулл соединений к бд, и одно из соединений входит в транзакцию на несколько минут. И вот round-robin на это соединение пошлёт запрос исполняться и он отвалится по таймауту, хотя рядом буду незанятые соединения

Не пощлет

Почему? Round-robin вообще не следит за состоянием занятости, он просто как-то упорядочивает воркеров и посылает следующему

Ну вот и ответ. Эту немного иначе, но если парадигма наследуется, то как-то так. Пошлет следующему, еще раз слудующему, пока пул не закончится. А потом Юрина проблема, что он закончился.

Ты что-то странное говоришь. Представь у тебя пул соединений к бд из 5 воркеров и 6 задачек из которых первая это транзакция на 10 минут, а все остальные исполняются очень быстро. Вот по round-robin у тебя на первого воркера прилетит огромная транзакция и шестая задачка, которая отлетит по таймауту, потому что воркер будет долго работать с транзакцией

Потому что хайлоад

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

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

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

Ясно, иди отдохни, дедуль

А что вообще за идея использования пула, зачем старичка пулбоя тормошить? Я как открыл для себя балансировку в духе N = erlang:phash2(Msg, ?NUM_OF_WORKERS), Worker = list_to_existing_atom(?MODULE_STRING ++ "_" ++ integer_to_list(N)), Worker ! Msg (разумеется не так грубо) так уже года так 3-4 как про пулы и gproc забыл

Вспомнился один очень старый проект, где помимо этого ещё проверялся размер очереди сообщений, чтобы «ровно» было. Вполне себе работало, до определенного момента. 😁