Skip to content

Allowing parallel_requests to be set on github.com #2715

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

SamuZad
Copy link

@SamuZad SamuZad commented Jul 30, 2025

Resolves #567


Before the change?

  • parallel_requests was explicitly disabled on github.com

After the change?

  • parallel_requests is no longer explicitly disabled on github.com

To paraphrase the rationale behind the change

With ~300 repositories, parallel_requests = false terraform plan -parallelism=30 68.65s user 23.16s system 19% cpu 7:46.27 total

With ~300 repositories, parallel_requests = true terraform plan -parallelism=30 44.51s user 14.47s system 105% cpu 55.640 total

With ~300 repositories, parallel_requests = true, lower parallelism terraform plan -parallelism=10 51.69s user 17.67s system 72% cpu 1:35.17 total

A significant reduction in plan time.

Of course, investigating the reason why it was implemented in such a manner, I've come across #145 and the linked official docs that say the following:

To avoid exceeding secondary rate limits, you should make requests serially instead of concurrently. To achieve this, you can implement a queue system for requests.

That being said, given that it makes such a massive difference, and this recommendation is specifically about the REST API (and a bunch of resources now interact with the GraphQL API instead which have more generous secondary rate limits)

Pull request checklist

  • Tests for the changes have been added (for bug fixes / features) - N/A
  • Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

  • Yes
  • No

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Slow performance when managing dozens of repositories
3 participants