ruby - bundle install/update too slow

Question

I just installed RVM, Ruby, Rails etc. on my virtual ubuntu 12.04 32bit running in a virtualbox. Now I encounter the problem that for my first rails project bundle install or bundle update takes very long time. Even when I create a new project with rails (which includes bundle install).

I use only the standard gems:

source 'https://rubygems.org'

gem 'rails', '3.2.12'

# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'

group :development do
  gem 'sqlite3', '1.3.5'
end


# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails',   '3.2.5'
  gem 'coffee-rails', '3.2.2'

  # See https://github.com/sstephenson/execjs#readme for more supported runtimes
  # gem 'therubyracer', :platforms => :ruby

 gem 'uglifier', '1.2.3'
end

gem 'jquery-rails', '2.0.2'

I tried bundle install without any gems but gem 'rails', '3.2.12'. After that I typed again bundle install with all gems in my gemfile. It took me 10 minutes to check for dependencies. The output of --verbose is a mix of HTTP success and HTTP redirection.

Rails version: Rails 3.2.12

Ruby version: ruby 1.9.3p392 (2013-02-22 revision 39386)

Rvm: rvm 1.18.18

bundle version: Bundler version 1.3.2

I already searched fot a solution, but nothing helped.

Solution 1

I want to warn: There is a security purpose for using https over http. Try at first the other answers mentioned in this thread.

Changing https to http in my Gemfile did the magic. Before I have to create the project with rails new APP --skip-bundle

Solution 2

Bundler just got an update of parallel processing of gems.

gem install bundler --pre 

will solve the problem in the best possible way for now.

Source

Solution 3

You can also use multiple jobs, it may improve a little bit

  bundle install --jobs 8

Here is a tutorial about it

Solution 4

Bundler v1.12.x was released in 2016 and caused some users to experience slow bundle install issues.

In this instance staying with v1.11.2 is the best option (it's fast) until a fix is released.

It's worth heading over to Rubygems.org to try different versions of the bundler gem.

Check existing bundler versions, uninstall existing version, install version 1.11.2 example:

gem list | grep bundler

gem uninstall bundler -v existing-version-number

gem install bundler -v 1.11.2

Solution 5

If you're still seeing this issue with Bundler 1.12.5, you may want to try updating the OpenSSL used by your Ruby.

For me this went like so:

pmorse$ bundle --version
Bundler version 1.12.5
pmorse$ ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'
OpenSSL 1.0.1j 15 Oct 2014
pmorse$ openssl version
OpenSSL 0.9.8zg 14 July 2015
pmorse$ brew info openssl
openssl: stable 1.0.2h (bottled) [keg-only]

[... more brew output ...]

pmorse$ rvm reinstall ruby-2.2.2 --with-openssl-dir=`brew --prefix openssl`

[... lots of rvm output ...]

pmorse$ ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'
OpenSSL 1.0.2h  3 May 2016

This should make bundle quicker again without requiring you to go from https to http.

View more solutions

Comments

[Nick]

I had the same problem on OS X with Rails 4 beta 1 and Ruby 2 and this fixed it. Changing https to http increased the speed of "bundle install" around 5-fold - from painful (minutes) to great (< 20 seconds). The main slow-down seems to be "Fetching gem metadata from rubygems.org..........." part.

[Lee]

Why does SSL make Bundler so slow?

[scaryguy]

Half of my Gemfile was executed for 1 hour... After using this way, it took just 5 minutes... THANK YOU for saving my night! But I don't understand what the hack is wrong with Ubumntu and rubygems?

[rosenfeld]

I don't think this is specific to Ubuntu or OS X as the same happens to me on Debian sid (unstable). Replacing https by http gives a super boost while running bundle for some reason...

[Roger]

@Nick and where do you change this (https -> http) ?

[Thomas Schwärzl]

@Rogier in your Gemfile - first line

[Roger]

@init3, ouch :/ Thanks found it, never noticed it their … ;-)

[viprs]

@Rogier the first line in your Gemfile.After change this, I just need less than one mins to 'bundle install'. really thank this topic.

[bfabry]

Given the high profile nature of rubygems.org this could be pretty dangerous. I'd say the only reason there hasn't been a high profile cache poisoning attack or similar yet is because gemfiles default to https. See: stackoverflow.com/questions/19559754/…

[spuder]

Possible reason why https is so slow is entropy exhaustion: github.com/cpuguy83/docker-jruby/issues/…

[mahemoff]

Looks like this is fixed now, that linked issue has been closed.

[pjmorse]

This will have the same security issues as other answers which suggest replacing https with http in the Gemfile, so be aware of the risk if you follow this.

[Reza Hashemi]

@pjmorse you are invalidating all answers while not adding much value. As I have noted, https still remains https, http is used in the backend as a mirror. It is apparent that we are replacing https in action with http and so we should be in a trusted environment. All https mentions in files remain https so there is no security risk if code is moved somewhere else.

[pjmorse]

Your answer is a valid solution to the question - that's why I didn't downvote it - but if you are fetching gems over http you are increasing your risk, whether you change the protocol in your gemfile or change the mirror configuration. Devs who choose this strategy should do so with their eyes open.

[Reza Hashemi]

I have actually upvoted your answer as a recent solution, but using encrypted gem transfer addresses very limited security risks. There is no reported attack vector using gem files modified on the way, in a man in the middle attack or similar. When the infrastructure or ISP is untrusted. All the http connections are insecure and the dev environment is under question. For example even the resource files and javascripts would be manipulated.