будут захлёбываться в потоке. может, это имелось в виду? самому rmq в целом пофиг, ну до тех пор, пока он все ресурсы не выжрет, в таком ключе много что лагать может
https://www.cloudamqp.com/blog/2018-01-08-part2-rabbitmq-best-practice-for-high-performance.html “eep your queue short (if possible) To get optimal performance, keep queues as short as possible. Longer queues require more processing overhead. We recommend that queues always stay around 0 for optimal performance.”
я думаю, тут речь уже о каких-то огромных значениях. но, опять же, если так критична скорость обработки большого числа сообщений, возможно, rmq не лучший выбор под этот кейс. выше уже всё сказали на эту тему как раз..
Понял. Нет не критична скорость.
Processing overhead. Это же явно на стороне консьюмера
Ну да на стороне консумера выростут затраты, если очередь держать полной. Как они утверждают.
Имеется в виду, так понимаю, что при разрастании очереди на кролике, он начнет скидывать ее на диск, естественно станет лагать, таская туда-сюда, потому либо обеспечивайте его достаточным количеством консьюмеров, либо ставьте подходящий TTL.
Обсуждают сегодня