mirror of
https://github.com/actions-runner-controller/actions-runner-controller.git
synced 2026-10-03 11:31:37 +02:00
The scaler issued every API call a message asked for before returning, and the listener acks only once it returns. A full batch of job started events is 50 of them, two calls each, so the next scale decision sat behind 100 calls of bookkeeping. Those patches are not what new jobs wait on. Only the desired runner count creates runners; Status.JobID is a hint the runner set consults when choosing which idle runner to delete, and the Actions service rejects the deletion of a runner whose job is still running either way. Publish the desired count first, hand the job started events to a background pool, and acquire after. Acquiring last costs the round trip of the scale patch and saves the whole batch, and the scale decision is unaffected: it comes from msg.Statistics, a snapshot the service took when it built the message, so jobs acquired now are reported as assigned in a later one. Give the two kinds of traffic their own clients. Sharing one token bucket is what let the job patches delay the scale patch, so splitting them is what makes the reordering worth anything; backgrounding alone would just move the same queue. Measured against a 5ms API server and a 50ms Actions service, at a full 50 event batch: scale patch reaches the API server 1.971s -> 6ms listener loop 2.02s -> 107ms/msg The loop no longer spends the rate limit inline, so its cost is now the two service round trips rather than the batch size. This does not raise throughput. Job patches still cost two calls per event, so the job client sustains qps/2 job starts per second, and the queue is bounded by the real job start rate rather than by how fast the listener polls: a faster loop polls more often and carries proportionally fewer events. Measured at qps 40, the queue stays empty through 18 starts/sec and degrades gradually past 20 rather than falling over. Close drains the queue, since the message these patches came from was acked long before they run. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>