Monday, April 1, 2013

Speed up your Bundle Install Process for Your Rails Application

Tired of waiting for your bundle install to complete?

Here's an easy fix that will likely work for you if you have not specified the version information for your gems in your Gemfile.

If you ran the bundle install (or bundle package) command previously, look in a file named Gemfile.lock for the version numbers of the gems specified in your Gemfile.


Gemfile.lock  << CLICK TO SEE DETAILS



Now edit your Gemfile:


Original Gemfile


source 'https://rubygems.org'

gem 'rails'
gem 'sqlite3'
gem 'jquery-rails'
gem 'thin'  # Use instead of webrick

group :assets do
  gem 'uglifier', '>= 1.0.3'
end

group :development, :test do
  gem 'rspec-rails'
end


Updated Gemfile


source 'https://rubygems.org'

gem 'rails', '3.2.13'
gem 'sqlite3', '1.3.7'
gem 'jquery-rails', '2.2.1'
gem 'thin'  # Use instead of webrick

group :assets do
  gem 'uglifier', '>= 1.0.3'
end

group :development, :test do
  gem 'rspec-rails', '2.13.0'
end


Now, when you run bundle install, it will go much, much faster because rubygems is not having to make extra trips to rubygems.org to look for the latest version of each gem.



Terminal Console Output  << CLICK TO SEE DETAILS


Add version (1.5.1) of the thin gem and add that version information in Gemfile:

gem 'thin', '1.5.1'  # Use instead of webrick


There are other issues that could be causing your gem dependency management system to run slowly, but this is a quick fix you can try.

The benefit is the obvious decrease in time it takes your bundle command to run.

The, debatable, disadvantage is that you will be using the specific version of gems that you specified in your Gemfile, i.e., not necessarily the latest versions.



What caused me to want to improve performance


I got a nagging error message in my log file and learned that I needed to add the Thin gem.


You, too, should consider replacing the WebBrick web server with Thin.  Doing so will eliminate the following noise in your log file:




=> Booting WEBrick
=> Rails 3.2.13 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2013-04-01 13:26:09] INFO  WEBrick 1.3.1
[2013-04-01 13:26:09] INFO  ruby 1.9.3 (2012-04-20) [x86_64-darwin12.2.0]
[2013-04-01 13:26:09] INFO  WEBrick::HTTPServer#start: pid=14125 port=3000
[2013-04-01 13:26:15] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/styles.css" for 127.0.0.1 at 2013-04-01 13:26:15 -0400
Served asset /styles.css - 304 Not Modified (4ms)
[2013-04-01 13:26:15] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/cordova-1.7.0.js" for 127.0.0.1 at 2013-04-01 13:26:15 -0400
Served asset /cordova-1.7.0.js - 304 Not Modified (3ms)
[2013-04-01 13:26:15] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true




References


Sponsor Ads


1 comment:

  1. some benchmarks how much time you saved via adding version numbers would be nice. i've tried it, but couldnt find any significant improvement.

    but the latest bundler version brings an awesome feature - parallel jobs, which saves a lot of time!
    source: http://robots.thoughtbot.com/post/59584648154/parallel-gem-installing-using-bundler

    ReplyDelete