Какое максимальное количество очередей(queues) может переварить Laravel?

Question

[Vadik7777]

Какое максимальное количество очередей(queues) может переварить Laravel?
При каком методе подключения очереди: database, redis и т.д.?
И какое максимальное, одновременное, асинхронное их количество может быть?

Есть задача, отправлять каждый час по 500К API запросов, чтобы за один час 500к уходили.

Comments

[JhaoDa]

Ты имел ввиду jobs. Переварить он может столько, сколько позволят ресурсы сервера. Или трёх. Или двух десятков.

[Vadik7777]

JhaoDa, да, выполнение jobs, так сказать без очередей, асинхронно.

[Дмитрий]

Vadik7777, ну ларавел тут не причем. сколько записей можно положить в базу? ну теоретически столько сколько места на диске.

[Максим Федоров]

Дмитрий, Ну если заменить ларавел го-приложением и разница будет, тогда ларавел тоже «не причем»? :)

[Дмитрий]

Максим Федоров, да тоже не причем. окей на go мы сможем обработать больше джобов в секунду (хотя возможно что джобы таковы что особой разницы нет, но возьмем что есть разница). Дальше то что? Мы можем сказать сколько максимум джобов может хранится у нас в приложении? Нет - потому что это не вопрос к приложению и на чем оно, это вопрос в меньшей степени к софту очередей и в большей степени железу, ни о первом ни о втором мы нихрена не знаем и в вопросе оно не стоит?. Мы можем сказать сможем ли мы обработать 500К джобов? Нет, потому что вообще нихрена не известно что мы делаем с результатом запросов к АПИ. Можем ли мы сказать - отправит ли приложение на laravel, на go, да на чем угодно - 500К запросов в час? Да хз, мы даже не знаем сколько один запрос отрабатывает, какие сетевые задержки, какой канал - вообще нихрена.

Вопрос звучит как может ли лошадь с шильдиком Laravel представленная в виде сферической точки в вакууме добежать до финиша? Может сможет, может нет. вероятность как у встречи динозавра - 50 на 50. А теперь меняем шильдик на что угодно - ответ поменяется? нет.

[Vadik7777]

Дмитрий, VPS 8 ядер, 16 гб RAM, канал 250мб/с, место на диске не ограничено. Результат запросов API записывается в таблицу базы. Ответ на 1 запрос получаем за 150-300мс.
И опять же как я понимаю метод подключения очередей также зависит, database большие объемы не тянет, там идут ошибки. Поэтому вопрос не только в железе.

Вы знаете как рассчитать мощность сервака под подобную задачу, чтобы точно знать что обработает 500к?

[Дмитрий]

Vadik7777, угу. есть такой вариант - взять и попробовать :), можно замокать апи и как минимум проверить что вы в свои лимиты не упретесь. Это лучше чем слушать людей в интернете, которые никогда не смогут на 100% понять контекст вашей задачи
как бы нагрузка штука не фига не линейная. и если 1 запрос у вас идет за 200 мс, два одновременно может быть, те же 300, а три запроса одновременно могут каждый уже за 1 с отрабатывать. То же самое может быть с БД, вы тупо можете при записи упереться в скорость записи диска. Смотрите на скорость диска - и смотрите сколько надо вам в нее писать. Канал - можно расчитать, смотреть сколько весит ответ и посмотреть сколько влезет.

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

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

[Vadik7777]

Дмитрий, спасибо за такой обширный ответ!

Answer 1

[Владислав Enokin]

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

В целом, возможно обрабатывать тысячи очередей в Laravel, но это в конечном итоге зависит от ресурсов, доступных на сервере и нагрузки на каждое задание в очереди. Если вам нужно обрабатывать большое количество очередей, вы можете рассмотреть использование пула рабочих очередей и настройку нескольких процессов для обработки нагрузки. Это поможет распределить нагрузку