Adjust the API_REQUEST_LIMIT to make less network roundtrip#9071
Merged
hsbt merged 1 commit intoruby:masterfrom Nov 13, 2025
Merged
Adjust the API_REQUEST_LIMIT to make less network roundtrip#9071hsbt merged 1 commit intoruby:masterfrom
hsbt merged 1 commit intoruby:masterfrom
Conversation
- ### Problem This limit is used when Bundler fallback to getting a dependency list from a server `/dependencies?gem=` endpoint. Bundler uses this API endpoint fallback when a server doesn't expose the compact index API. This is not used for Rubygems.org, only private servers. This limit is then divided by the number of dependency to get and the result is the number of request we'll be doing. The bottleneck on the client is the network roundtrip. On the server, getting the info of 50 or 100 gems is a bit more expensive but this operation is heavily cached. This is an example of Rubygems.org implementation at the time the dependencies API wasn't deprecated https://github.com/rubygems/rubygems.org/blob/5a3a3ec02acc3a4e3aba077953a393ad20a06842/app/models/gem_dependent.rb#L15 ### Context This limit used to be 100 a while ago but got changed to 50 in ruby@e745f8d I don't know why. ### Solution 50 gems to query seems arbitrary low. By doubling this number, we make twice as less API requests which ultimately can shove up to two seconds on application relying on a large number of gems.
65e1627 to
8318940
Compare
Member
|
That's reasonable. We can revert this if we faced some problem. |
hsbt
approved these changes
Nov 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was the end-user or developer problem that led to this PR?
Getting a list of gems 50 per 50 is too slow and seems arbitrarily low.
This limit is used when Bundler fallback to getting a dependency list from a server
/dependencies?gem=endpoint. Bundler uses this API endpoint fallback when a server doesn't expose the compact index API. This is not used for Rubygems.org, only private servers.This limit is then divided by the number of dependency to get and the result is the number of request we'll be doing. The bottleneck on the client is the network roundtrip. On the server, getting the info of 50 or 100 gems is a bit more expensive but this operation is heavily cached.
This is an example of Rubygems.org implementation at the time the dependencies API wasn't deprecated https://github.com/rubygems/rubygems.org/blob/5a3a3ec02acc3a4e3aba077953a393ad20a06842/app/models/gem_dependent.rb#L15
What is your fix for the problem, implemented in this PR?
50 gems to query seems arbitrary low. By doubling this number, we make twice as less API requests which ultimately can shove up to two seconds on application relying on a large number of gems.
Worth noting that the limit used to be 100 but got changed in e745f8d for a reason I ignore.
Make sure the following tasks are checked