-
Notifications
You must be signed in to change notification settings - Fork 15
Description
TL;DR
Summarize rate limit points and avoid the limit by self-regulation.
Self-regulate the client to avoid the limit, and, thus, the >=60s sleep.
Please thumb-up or comment if you are interested in that (not sure I'll do it otherwise).
Details
Github Support:
Make too many concurrent requests. No more than 100 concurrent requests are allowed. This limit is shared across the REST API and GraphQL API.
Make too many requests to a single endpoint per minute. No more than 900 points per minute are allowed for REST API endpoints, and no more than 2,000 points per minute are allowed for the GraphQL API endpoint. For more information about points, see Calculating points for the secondary rate limit.
Design Thoughts
The general idea is to have middleware that throttles by increasing a count on the way out, and decreasing it on the way back.
This solves the <100 concurrent requests issue, and a simple weighted non/blocking semaphore would do here (namely, the x/sync version).
The more advanced cases (900 points per minute, 90s/60s CPU usage, etc.) would require even more complexity,
such as sliding windows and ping-pong time measurement.
So, let's not go there unless we really have to.