Почему через celery (rabbit и пр. очереди сообщений) не рекомендуется передавать большие массивы данных (как аудио или видео)?

Question

[LakeForest]

Почему через celery (rabbit и пр. очереди сообщений) не рекомендуется передавать большие массивы данных (как аудио или видео)?

Answer 1

[Сергей]

Потому-что брокеры сообщений не сильно хороши в таком. В целом такое можно сделать (предварительно настроив брокер), но производительность системы упадёт на столько, что следующим Вашим вопросом будет: "Почему так тормозит". От брокеров обычно ждут минимальный отклик, поэтому стараются сократить сообщения до минимально возможного.

Comments

[LakeForest]

А не подскажете, можно ли это чем-то подтвердить, как-то на практике показать, что действительно производительность падает? Может есть какая-то книга, откуда вам это стало известно?

[Сергей]

К сожалению, книг я не знаю, да и статей, которые бы показывали почему нельзя так делать с цифрами.
Тут всё индивидуально, например, если у вас сервер с RabbitMQ имеет 100ГБ/с сеть, супер быстрые диски с достаточным объёмом, много оперативной памяти для кэша, а в свою очередь Вам надо отправить 100 видео в минуту по 50МБ каждое, то RabbitMQ и остальные пользователи такое даже не заметят.
Самое действенное и правильное - поднимите систему, которая ожидается в продакшете (или близкую к ней), и отправьте нагрузку которую ожидаете. Помониторьте день когда всё идет по плану, потом отрубите потребителей, подайте 2х/10х нагрузку и оцените, если такое поведение подходит.

Одной из проблем больших сообщений помню было то, что RMQ хранит сообщения в журналах (не деля на очереди), разбивая на куски по, например, 10ГБ и удаляя куски, когда все сообщения прочитаны. И если в таком журнале оказывается сообщение из неактивной очереди, часть журнала будет жить вечно. А если количество больших сообщение велико, то таких кусков журнала тоже будет велико.