Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
A quick rubygems proxy server
Ruby
Branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
app
config
db
doc
lib
log
public
script
vendor/plugins
.gitignore
Gemfile
Gemfile.lock
README.rdoc
Rakefile
config.ru

README.rdoc

Welcome to Gemz Bond

We hope to reduce the time you spend doing bundle updates, especially with bundler before 1.1.

This SHOULD be deployed by passenger, or I cannot guarantee page caching will work (and without page caching, this becomes really slow)

Is this for developers to speed up their build time?

It might, but this is targetted mostly for large teams, and build and deploy agents that need a gems cache. This is especially usefull when you are on a relatively slow net connection.

What is the trade off

  • The first call will be really really slow (1.5x the time). But you should get speed benefits after that

  • You have to invalidate the specs.gz cache when you want new gems to flow in. This can be done by running: RAILS_ENV=production rake recalculate

  • If you filter out gems that should be returned, you will have an extra step if you add a gem to your project.

How do I use this?

Deploy gemz_bond on any machine that is serving passenger. Set the permissions as 777 on the public folder (for page caching):

chmod 777 -R public/

Change the first line of your gemfile to use this as a source

Change from:

source :rubygems
source "http://rubygems.org"

to:

source "http://my.gemz_bond.server:port"

How Do I configure this?

Looking at the config/gem_server.yml will provide you the answers you need. There are two configs:

  • rubygems => The URL to rubygems.org (or where to forward the request in general)

  • filter_specs => This can have the following values

  • false

  • a list of names like [foo, bar, baz]

  • a list of names in YAML format

How does it work

Short answer: We do lots of page caching with rails (acts as a proxy). We also let you specify what gems to keep, and which gems to ignore in the specs.gz

There are three major kinds of HTTP calls that bundler makes to a gem source in the 1.0 series:

  • GET /specs.4.8.gz <– This is an index of all gems. At the very least, we cache this locally. We also give you the option of filtering out which gems are returned by this call in the gem_server.yml. This is currently 700 kb, and really slow query to parse in memory (which bundle has to do). Page cache me (after optionally filtering out unwanted gems)

  • GET /prerelease_specs.4.8.gz <– Same as above, but for unreleased gems. Ditto as above

  • GET /quick/Marshal.4.8/foo-1.2.3.gemspec.rz <– This is what slows down bundler a lot. It keeps polling this to build a graph of gems. This never changes. Page cache me.

  • GET /gems/foo-1.2.3.gem <– The actual gem. This never changes. Page cache this too :-).

Copyright

This is Copyright © Tejas Dinkar, C42 Engineering and Flipkart. This is available under the MIT license.

Something went wrong with that request. Please try again.