так воркеры задачи из очереди не берут и все...

внешний провайдер не гарантирует время ответа, так что асинхронная обработка нужна

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

оно так и сделано сейчас. но, если у нас увеличивается количество серверов - надо запускать отдельный celery worker на новую очередь.
а если время ответа растет - надо увеличивать количество тредов динамически.

и как-то вот это мне все не нравится)

ну, пока непонятно) видимо придется упомянуть, что запросы идут через прокси, и это они, скорее всего, увеливают latentcy. API готово принимать запросы с определенным rate limit'ом

но на вашей стороне это понять непросто, можно трекать ttfb и от него плясать высчитывая типа true rate limit и изменяя кол-во исходящих запросов, но как-то это хрупко очень можно и ту сторону завалить и себя перегрузить в случае если на той стороне проблемы

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

ну в целом token bucket со стратегией анализа response time и изменением кол-аа токенов динамически вроде как нормальный выход

я это посмотрел и идея вроде бы ничего.

но есть одно но. в простом случае у нас таска идет вида:
1. взяли что-то из базы
2. сделали запрос к API
3. сохранили ответ в БД

но в более сложном
1. взяли из базы
2. сделали несколько запросов к API
3. обработали данные
4. сделали еще один запрос к API
5. сохранили в БД

используя этот подход я так понимаю придется дробить задачи на много мелких, тогда на задачу-запрос к API можно повесить такой rate-limit. но создавать и управлять такими микро-задачками будет сложновато на мой взгляд.

Разделяй и властвуй

кстати, нашел недавно вот такую штуку для создания цепочки celery задачек: https://ovh.github.io/celery-director/

но как-то это все выглядит устрашающе.

Имхо апилимит/количество воркеров - сделать сегодня

хотя переписать все на asyncio/aiohttp будет, наверное, еще дольше)

А переписать на token bucket на след неделе

так оно не будет работать если у нас API/прокси стала в 2 раза медленее ответ отдавать.

в вашем примере
> ок, api может в 10 запросов в минуту, у нас 5 worker'ов, поставим им 2r/m и радуемся жизни

10 запросов в минуту - это очень хорошие условия)

что если нужно делать 10 запросов в секунду? при этом API может ответить за 1 секунду, а может за 2.
если сделаем 10 потоков с ограничением 1 задача в секунду, тогда при скорости ответа 1 секунда все будет ок. а если будет 2 секунды - мы тогда будет ждать вместо того, что сделать следующие запросы.

это же не упростит архитектуру, только сэкономит ресурсов и увеличит возможно пропускную способность в сложных сценариях, это имхо nice to have в вашем случае

у вас синхронная обработка на celerey, так?

в смысле, хороше бы на asyncio переделать? я этом случае придется я так понимаю вообще все переделать на асинхронщину, а на это ресурсов нет( плюс там встают проблемы с асинхронной работой с БД.

поэтому я всеми силами пытаюсь остаться на селери и что-то придумать с ним. готовы даже на неоптимальное использование железа (т.е. тупо взять больше серверов)

да

в смысле что не стоит, это мало чем поможет в решении описанной проблемы а ресурсов может много съесть