Increase connection pool to allow for up to 70% speed increase on bundle install

[Edouard-chin]

What was the end-user or developer problem that led to this PR?

TL;DR

Bundler is heavily limited by the connection pool which manages a single connection. By increasing the number of connection, we can drastically speed up the installation process when many gems need to be downloaded and installed.

Benchmark

There are various factors that are hard to control such as compilation time and network speed but after dozens of tests I can consistently get aroud 70% speed increase when downloading and installing 472 gems, most having no native extensions (on purpose).

# Before
bundle install  28.60s user 12.70s system 179% cpu 23.014 total

# After
bundle install  30.09s user 15.90s system 281% cpu 16.317 total

You can find on this gist how this was benchmarked and the Gemfile used https://gist.github.com/Edouard-chin/c8e39148c0cdf324dae827716fbe24a0

Context

A while ago in #869, Aaron introduced a connection pool which greatly improved Bundler speed. It was noted in the PR description that managing one connection was already good enough and it wasn't clear whether we needed more connections. Aaron also had the intuition that we may need to increase the pool for downloading gems and he was right.

We need to study how RubyGems uses connections and make a decision based on request usage (e.g. only use one connection for many small requests like bundler API, and maybe many connections for downloading gems)

When bundler downloads and installs gem in parallel most threads have to wait for the only connection in the pool to be available which is not efficient.

rubygems/bundler/lib/bundler/installer/parallel_installer.rb

Lines 122 to 124 in 4f85e02

	def worker_pool
	@worker_pool ||= Bundler::Worker.new @size, "Parallel Installer", lambda {|spec_install, worker_num|
	do_install(spec_install, worker_num)

What is your fix for the problem, implemented in this PR?

This commit modifies the pool size for the fetcher that Bundler uses. RubyGems fetcher will continue to use a single connection.

The bundler fetcher is used in 2 places.

1. When downloading gems

   rubygems/bundler/lib/bundler/source/rubygems.rb

   Lines 481 to 484 in 4f85e02

   	def download_gem(spec, download_cache_path, previous_spec = nil)
   	uri = spec.remote.uri
   	Bundler.ui.confirm("Fetching #{version_message(spec, previous_spec)}")
   	gem_remote_fetcher = remote_fetchers.fetch(spec.remote).gem_remote_fetcher

2. When grabing the index (not the compact index) using the bundle install --full-index flag.

   rubygems/bundler/lib/bundler/fetcher/index.rb

   Line 9 in 4f85e02

   Bundler.rubygems.fetch_all_remote_specs(remote, gem_remote_fetcher)

Having more connections in 2) is not any useful but tweaking the size based on where the fetcher is used is a bit tricky so I opted to modify it at the class level.
I fiddle with the pool size and found that 5 seems to be the sweet spot at least for my environment.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[Edouard-chin]

Without this patch, this test would deadlock

[Edouard-chin]

I figured it could be valuable to share the profile of before/after, so here they are:

Before

The threads spend most of the time just waiting.

After

Now they are busy most of the time.

[hsbt]

🙏 Thanks for detailed information. I would like to merge this until 4.0.0 final. But I'm in a situation where I don't have time to reviews.

[Edouard-chin]

Thanks for all your work , no rush at all. Just wanted to provide this information.