You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My organization has a lot of GitHub data that we want to perform nightly backups of to a Drobo. I have been attempting to use this program to build it out, but I keep hitting the API rate limit, which times out the request for an increasing amount of time. Is there a way to tell the program to limit it's requests so that the data coming in is steady but not hitting the 5000 requests per minute threshold?
The API rate limit is 5000 HTTP requests per hour (not minutes as said above).
Let's say we want to backup issues.
A repo with more than 5000 issues, it starts to become a problem.
The theoritical limit is
1.38888 requests per second.
So we could artificially set a timer with one request per second and we would be safe.
A backup for issues in a repo of 40,000+ issues would "only " take 11h6m40s.
I've created a very simple throttling approach in #149.
This is not very clever and it simply pause API requests a fixed amount of seconds but it helps to stay within the rate limits.
My use case is: the GitHub API user used for the backup is also used elsewhere. It doesn't matter how long the backup takes as long as there are a few API requests left for the other uses.
I am successfully using @eht16's throttling (💙) to keep below the rate limit when backing up very large orgs. I'm using --throttle-limit 5000 --throttle-pause 0.6 but YMMV. IMO @eth16's work should close this issue 👍
Activity
josegonzalez commentedon Dec 26, 2017
There is not. Pull requests welcome.
karlcow commentedon Oct 15, 2019
The API rate limit is 5000 HTTP requests per hour (not minutes as said above).
Let's say we want to backup issues.
A repo with more than 5000 issues, it starts to become a problem.
The theoritical limit is
So we could artificially set a timer with one request per second and we would be safe.
A backup for issues in a repo of 40,000+ issues would "only " take 11h6m40s.
python-github-backup/bin/github-backup
Lines 453 to 454 in fac8e42
python-github-backup/bin/github-backup
Lines 409 to 451 in fac8e42
There is also this piece of code which use rate limiting but only in case there's already an error.
python-github-backup/bin/github-backup
Lines 505 to 534 in fac8e42
The strategy could be slightly different.
eht16 commentedon Apr 13, 2020
I've created a very simple throttling approach in #149.
This is not very clever and it simply pause API requests a fixed amount of seconds but it helps to stay within the rate limits.
My use case is: the GitHub API user used for the backup is also used elsewhere. It doesn't matter how long the backup takes as long as there are a few API requests left for the other uses.
garymoon commentedon May 29, 2020
I am successfully using @eht16's throttling (💙) to keep below the rate limit when backing up very large orgs. I'm using
--throttle-limit 5000 --throttle-pause 0.6but YMMV. IMO @eth16's work should close this issue 👍