Open mikecote opened 2 days ago
Pinging @elastic/response-ops (Team:ResponseOps)
Seems like it would be nice to have all the claiming-rate bits in one place - it gets fed various inputs (the 429's etc, and now number of tasks claimed over last cycle(s)) - and generates a new rate. So we don't have the logic spread out all over the place ...
Another thing we can do is check for upcoming tasks to run - nothing? Then sleep a bit longer ...
Maybe the claimer could search a bit in the future as well, and determine if there is anything coming up soon ...
When enabling
mget
as the task claim strategy, the task poll interval currently changes from every3s
to every500ms
, creating 6x the requests to Elasticsearch to claim tasks. Lowering the poll interval was added to increase the per-node task throughput. However, when observing the request load to Elasticsearch for small serverless projects that don't run many tasks, the Task Manager performs a lot of requests for little of a return.It would be nice to poll less frequently whenever the task load doesn't need to, say back to
3s
in such situations. We should take the following into consideration when coming up with an approach:Definition of Done
3s
whenever the task load doesn't need a500ms
poll interval