Оптимизация сельдерея для сторонних HTTP-звонков

Question

Мы используем сельдерей, чтобы сделать сторонние HTTP-звонки. У нас есть около 100 задач, которые просто вызывают вызовы API-интерфейса сторонних разработчиков. Некоторые задачи вызывают API навалом, например, полмиллиона запросов в 4 часа утра, в то время как некоторые из них представляют собой непрерывный поток вызовов API, получающих запросы почти один или два раза в секунду.

Большая часть времени ответа на вызов API составляет от 500 до 800 мс.

Мы видим очень медленные скорости доставки с сельдереем. Для большинства из вышеперечисленных задач максимальная скорость доставки составляет около 100/с (макс.) До почти 1/с (мин). Я считаю, что это очень плохо, и что-то определенно неправильно, но я не могу понять, что это такое.

Мы начали с кластера из 3 серверов и поэтапно сделали его кластером из 7 серверов, но без каких-либо улучшений. Мы попытались с различными настройками параллелизма от автомасштаба до фиксированных 10, 20, 50, 100 работников. Нет никакого результата, и наш брокер - RabbitMQ.

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

--time-limit=1800 --maxtasksperchild=1000 -Ofair -c 64 --config=celeryconfig_production

Серверы 64 G ОЗУ, CentOS 6.6.

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

Должны ли мы идти с gevents? Хотя я понятия не имею, что это такое.

Answer 1

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

Я не уверен, что цельный сельдерей - хорошая идея в вашем случае. Это отличное программное обеспечение с большой функциональностью. Но если это не нужно, лучше использовать что-то более простое - на всякий случай некоторые из этих функций мешают. Я бы написал небольшой PoC, проверьте другое клиентское программное обеспечение, например pika. Если это не поможет - проблема связана с инфраструктурой. Если помогает - у вас есть решение. :)

Очень сложно сказать, что происходит. Это может быть что-то с IO или слишком много сетевых вызовов ... Я бы отступил - чтобы узнать что-то работающее. Записывайте интеграционные тесты, но обязательно используйте 2-3 машины, чтобы использовать полный стек tcp. Обязательно иметь CI и запускать эти тесты один раз в день или около того - чтобы убедиться, что все идет в правильном направлении.