СИ
Заляпаный листочек? Когда делаешь пул, надо есть. Кормить мозг.
стикеры неприличные все стали - большие и двигаются.
Size: a a a
2020 March 16
AK
Не, проект не домашний. Конкретно есть Ковбой с кучей входящих сообщений и есть БД, которая ограничена. Если делать пул к БД, то вопрос - нормально ли накапливать входящие вызовы, чтобы БД их постепенно разгребала?
Нормально до определенного предела. После этого предела похорошему надо возвращать в http "server too buzy"
s
Нормально до определенного предела. После этого предела похорошему надо возвращать в http "server too buzy"
Спасибо! В принципе у нас была такая задумка.
AK
Но вариантов кучи.. клиентов очень много? их можно синхронно подтормаживать, пока не сохранилось в базу ответ не отдавать
СИ
Не, проект не домашний. Конкретно есть Ковбой с кучей входящих сообщений и есть БД, которая ограничена. Если делать пул к БД, то вопрос - нормально ли накапливать входящие вызовы, чтобы БД их постепенно разгребала?
нормальность - это относительное понятие. ты имеешь ввиду допустимо ли залипание запросов до начала выполнения? это тебе решать. но если ты делаешь залипание, то надо предусмотреть и таймауты - а это опять работа
ММ
Не, проект не домашний. Конкретно есть Ковбой с кучей входящих сообщений и есть БД, которая ограничена. Если делать пул к БД, то вопрос - нормально ли накапливать входящие вызовы, чтобы БД их постепенно разгребала?
а клиент готов ждать, когда до него дойдет дело? если нет, то такая схема не подойдет, придется расшивать узкое место
SP
Пока все эти вопросы висят в воздухе, т.к. приложение находится на стадии прототипирования. Пока предполагается что количество будет ограниченное, поэтому остальные будут отбрасываться. Мне важна была сама концепция в рамках ерланга. Всем спасибо за советы!
Тут буквально неделю назад обсуждали пулы
SP
11 марта если точнее
СИ
Пока все эти вопросы висят в воздухе, т.к. приложение находится на стадии прототипирования. Пока предполагается что количество будет ограниченное, поэтому остальные будут отбрасываться. Мне важна была сама концепция в рамках ерланга. Всем спасибо за советы!
отбрасываться сразу и отбрасыватья по таймауту - это разные концепции
AK
11 марта если точнее
Сегодня был вопрос немного другой, про выравнивание нагрузки к относительно медленной базе. Тоесть пул, но теперь с очередью, одной общей или отдельными для каждого воркера выяснить пока не удалось. Как и с синхронностью асинхронностью
ММ
что-то мне подсказывает, что там пока даже не ясно какие запросы к базе ходить будут. может там 99% чтение, а может наоборот. и возможные решения будут сильно разными.
LL
Да, пока не особо ясно. Пока вставал вопрос, как организовать работу с БД и другими похожими сервисами. Стоит ли организовывать очереди и предоставляет ли OTP примитивы для этого.
Процесс - это отчасти и очередь сообщений в функцию
Так что примитив есть (это шутка, ха-ха)
Так что примитив есть (это шутка, ха-ха)
SP
Сегодня был вопрос немного другой, про выравнивание нагрузки к относительно медленной базе. Тоесть пул, но теперь с очередью, одной общей или отдельными для каждого воркера выяснить пока не удалось. Как и с синхронностью асинхронностью
ну у того же pooler есть параметр
timeout. Если его добавить, то клиент будет ждать доступного воркера до таймаута. Т.е. в каком-то смысле очередь. Если задать таймаут как 0, то сразу отвалится если нет свободных воркеров https://github.com/seth/pooler/blob/9c28fb479f9329e2a1644565a632bc222780f1b7/src/pooler.erl#L187-L204
AK
а размер очереди говорит?
AK
чтобы сразу отлупить если очередь длинная
SP
не думаю
SP
но очередь там внутренняя, не message queue. Т.е. при необходимости можно реализовать и такое. Хотя звучит как сомнительная эвристика