Currently, tasks execute pending outgoing network requests eagerly, like those in the polling engine. After that, the engine sleeps for a long time. This has the effect of potentially spamming the same service with many requests, when in theory the requests could have been equally spaced out over a much longer period.
For example, the polling engine runs every 5 minutes (300 seconds). If there are 20 branches to poll, the server sends 20 requests to GitHub in 1 second and then sleeps for the remaining 299 seconds. My idea is instead to equally space out those requests. Using the same example, a different request is sent every 300 / 21 ~ 14.3 seconds (I used 21 and not 20 because otherwise the request at the end of the first train is sent at the same time of the request of the second train).
I did a quick search, and I noticed there is an ecosystem crate governor which implements the Generic cell rate algorithm (GCRA). Given the small package size, I might consider adding it.
Currently, tasks execute pending outgoing network requests eagerly, like those in the polling engine. After that, the engine sleeps for a long time. This has the effect of potentially spamming the same service with many requests, when in theory the requests could have been equally spaced out over a much longer period.
For example, the polling engine runs every 5 minutes (300 seconds). If there are 20 branches to poll, the server sends 20 requests to GitHub in 1 second and then sleeps for the remaining 299 seconds. My idea is instead to equally space out those requests. Using the same example, a different request is sent every
300 / 21~ 14.3 seconds (I used 21 and not 20 because otherwise the request at the end of the first train is sent at the same time of the request of the second train).I did a quick search, and I noticed there is an ecosystem crate
governorwhich implements the Generic cell rate algorithm (GCRA). Given the small package size, I might consider adding it.