ну, в нашем случае таска может быть такой
1. взяли из БД - 50 мс
2. дернули API - 800 мс - 2000 мс
3. сохранили в БД - 50 мс

т.е. таска может быть от 900 до 2100 мс. примерно. и мы это время просто сидим и ждем ответ от API. хотя API готово принимать еще запросы. но кол-во тредов у нас фиксировано.

ок, дано
- api limit 10r/s
- 10 worker'ов
если api отвечает за 2 сек, мы упираемся в пропускную способность api , а не в лимит

а, это хорошо 🙂

в API можно отдавать запросы 10 в секунду. а то что она ответ отдавать будет по 2-3 секунды - ну и ладно)

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

ну, это гипотеза такая

но вообще мы дошли до места где далее ставить диагноз и назначать лечение по фотографии - сложно)

сделаем 20 воркеров с 0.5task/sec

хехе 🙂

да! вот бы оно еще динамически как-то делалось

но celery выпилили autoscale

где крутится код?

эм.. на EC2 инстансах в AWS'е. 4 Gb RAM, 2 ядра. там же еще API сервиса крутится, Redis и другие воркеры

меня интересует где крутятся воркеры

- таймауты
- circuit breaker
- лимитер
- ретраер
- api gateway

если интересны детали стучитесь в личку, расскажу

не совсем понял вопрос

написал

думаю проще через token bucket сделать чем мониторинг очереди и редеплой воркеров с изменением лимита...

ну да, я к этому варианту тоже склоняюсь.

но тут 2 варианта я вижу:
1. дробить задачи на микрозадачи и запрос к API выносить в отдельную очередь, на которую вешать rate limit, как описано здесь: https://habr.com/ru/post/494090/. но повторюсь, код будет очень замороченным. но плюс в том - мы можем отдельно масштабировать воркеры, которые делают запросы к API.

2. как вариант, непосредственно перед самим запросом впилить свой token bucket, который будет брать токен и делать запрос. но тогда другие треды будут перед запросом сидеть и ждать свою очередь. в этом случае текущий код тасок останется без изменений, но масштабировать будет сложнее.

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