rubygems and bundler are super slow

[lephyrius]

I have tried running my application. The only thing that are slow is rubygems and bundler. Locally it's fast. But on the server it's slow. I have tried:

bundle install --jobs 64 --clean --verbose --deployment --binstubs --without test development

Is slow!

bundle install --jobs 4 --clean --verbose --deployment --binstubs --without test development

Is slow!

bundle install --jobs 4 --without test development

Is slow!

gem install bundler

Is slow!

gem update --system

Is slow!

apt-get install -y git zopfli parallel nodejs

Is fast!

curl --verbose https://bundler.rubygems.org/api/v1/dependencies

Is fast!

curl -I https://rubygems.global.ssl.fastly.net/quick/Marshal.4.8/tzinfo-1.2.2.gemspec.rz

Is fast!

rake assets:precompile --trace

Is fast!

torquebox run -p 4000 -e production

Is fast!

puma -t 8:128 -p 4000 -e production

Is fast! I have also tried: FROM jruby:9.0-jre and FROM jruby:9.0-jdk

I see no difference....

Could this be a ruby problem?

I use docker version:

Containers: 94
Images: 305
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 493
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
CPUs: 4
Total Memory: 7.816 GiB
WARNING: No memory limit support
WARNING: No swap limit support

Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.5.1
 Git commit:   0a8c2e3
 Built:        Fri Sep 11 01:46:35 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:08:05 UTC 2015
 OS/Arch:      linux/amd64

Here is my JRUBY opts: JRUBY_OPTS = --server -J-Xmn512m -J-Xms1024m -J-Xmx2g -J-XX:+UseCompressedOops -J-XX:+UseCodeCacheFlushing -J-XX:+CMSClassUnloadingEnabled -J-XX:+UseConcMarkSweepGC -J-XX:ReservedCodeCacheSize=128m

Is there some way to speed up the bundler/gem command? It's almost as if they have some handshake issue? Maybe SSL? The things is that the CPU is idle when gem/bundle starts. Is this a jRuby issue? Is there something I could do?

[lephyrius]

Ok! I found the solution. The reason it was slow was because of entropy exhaustion: https://github.com/jruby/jruby/wiki/Improving-startup-time#ensure-your-system-has-adequate-entropy https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

So I would just add: RUN apt-get install haveged Modify: /etc/default/haveged with DAEMON_ARGS -w 1024 update-rc.d haveged defaults

OR maybe install it from source.

To every single dockerfile. IF u don't think that's a good idea then just add that to the documentation. Here I was thinking that jRuby was super slow but it isn't. It's extremely high performant. Hopefully it will help more people than me.

[cpuguy83]

Interesting! Thanks for the investigation!

[Bill]

Good research @lephyrius. However, for me, the answer over here was easier and better:

http://stackoverflow.com/questions/26021181/not-enough-entropy-to-support-dev-random-in-docker-containers-running-in-boot2d

The idea is to simply mount /dev/urandom (the nonblocking random source) from the host as /dev/random in the container. Nice thing about this is, if you are running on OS X (as I am), it affects only the dev environment. I'm not modifying my Docker images, so I'm not changing the behavior in my production environment.

This brought initialization times for one of my jruby containers from around 3 minutes to around 30s.

[cpuguy83]

Sounds like all that would be needed would be to seed /dev/random with something like haveged

Closing as this is not really a problem with the image itself and not something that's solvable at this layer in the stack.

[rosenfeld]

From my experiences, running bundler with JRUBY_OPTS="--dev" reduced the total time to half of the original time...