Неудовлетворительная производительность при отправке заданий с помощью Python RQ

Пытаемся использовать python-rq для поддержки серверной части нашего веб-приложения, но отправка новых заданий занимает очень много времени — до 12 секунд.

Падение производительности происходит при выполнении вызова функции enqueue_call, особенно когда количество рабочих процессов, подключенных к системе, увеличивается (более 200).

Система работает следующим образом:

  1. Внешний интерфейс отправляет задания на сервер очереди задач. При этом используется функция enqueue_call для передачи аргументов заданию (таких как время ожидания и ttl) в дополнение к фактическим аргументам функции, которая должна быть выполнена.
  2. В нескольких процессах (распределенных по нескольким машинам) запущены рабочие процессы, каждый из которых находится под UNIX screen. Рабочие следуют шаблону, представленному в документации, выполняя функцию бесконечного цикла Worker.work() для прослушивания очередей.
  3. Во время обработки некоторые задачи порождают новые, обычно в той же очереди, в которой они выполняются.

Об инфраструктуре:

  • Сервер Redis, на котором выполняется эта очередь задач, выделен для нее. Кроме того, постоянство отключено. Он работает на сервере Rackspace объемом 4 ГБ.
  • При запуске redis-benchmark на сервере с очередью задач мы получаем результаты более 20000 r/s в среднем для большинства бенчмарков.

Как мы можем улучшить производительность push-уведомлений для новых заданий в такой ситуации? Есть ли лучший шаблон, который мы должны использовать?


python asynchronous redis task-queue python-rq
person Juan Carlos Coto    schedule 11.03.2013    source источник
comment
Переключение (на сельдерей) значительно улучшило производительность? Я испытываю ту же проблему.   -  person David Hagan    schedule 18.08.2015
comment
В настоящее время я больше не работаю над одним и тем же проектом. Тем не менее, мы продолжали использовать rq в качестве серверной части, и проблемы с производительностью в конечном итоге были устранены, когда мы очистили инфраструктуру. Я не могу рекомендовать переходить на celery или оставаться на rq для вашего конкретного случая использования; Однако я предлагаю провести тесты. Это может быть не так сложно, как вы думали изначально, и я гарантирую, что любое время, потраченное на создание хороших тестов, в конечном итоге окупится, поскольку вы лучше поймете природу своей системы. Удачи!   -  person Juan Carlos Coto    schedule 29.08.2015

Ответы (1)


arrow_upward
0
arrow_downward

12 секунд? Это безумие.

Рассматривали ли вы возможность использования celery?
Никогда не использовали redis-rq, но, судя по документам, он не очень хорош для большого количества рабочих процессов
Очередь Redis обычно основана на команде BLPOP, которая может работать с несколькими клиентами , но кто знает, сколько он реально может выдержать за один ключ.

Поэтому я предлагаю вам перейти на Celery или написать свой собственный распределитель задач для python-rq, что не будет проще, чем переход

person Tigra    schedule 24.03.2013