So my exact case is that I have ~1400 domains on an ancient, self-hosted bind server and I'm looking to migrate them to a hosted service. The trouble is that the hosted service's API has a rate limit of 150 requests per 300 seconds and each domain will require at least 3 requests to migrate. [Note: This API does not provide any quota information, it simply stops working with a generic error message.
If I were to simply hard-code a 2-second sleep between requests I'd end up with 6+ seconds of API calls, plus an additional ~2 seconds to retrieve/reformat records from the legacy server. This clocks me in at around 3.1 hours for the migration, which is a hefty ask.
Another alternative that I considered was adding a
$last_call variable that I could use to calculate a sleep to add up to 2 seconds since the last call, but that still doesn't account for the time spent outside of the API client/calls.
Lastly I've tried keeping a list of millisecond timestamps representing each call, counting how many have occurred in the last 300 seconds, and dividing the window equally among them. However I've found that this tends to result in longer-than necessary sleeps at the beginning of the first window, frantically small sleeps at the end, and a call rate somewhat lower than the configured limit. This repeats in a cycle and does not seem to average itself out very much even over the course of a couple hours.
Is there a particular method or algorithm that would be well-suited to more evenly coordinating these requests within the given rate limit?