CARVIEW |
Navigation Menu
-
-
Notifications
You must be signed in to change notification settings - Fork 927
Description
I've been using jRuby in development for a while now and now I've set up a virtual machine host here as the staging server, and a production server is hosted at Linode (I just mention that as it affects that server too and they know what they're doing...)
here's a profile I did trying to work out how come various things were taking forever, including starting my tests and actually starting the site in puma.
main profile results:
Total time: 384.40
total self children calls method
----------------------------------------------------------------
381.72 0.09 381.63 5692 Kernel.require
379.42 0.21 379.21 54 Kernel.load
378.98 0.14 378.84 9149 Array#each
378.50 0.28 378.22 139 Kernel.eval
377.02 0.00 377.02 1 Rake::Application#run
377.02 0.00 377.02 3 Rake::Application#standard_exception_handling
375.16 0.00 375.16 5620 Proc#call
373.16 0.01 373.15 905 ActiveSupport::Dependencies::Loadable.load_dependency
373.07 0.01 373.07 880 ActiveSupport::Dependencies::Loadable.require
372.16 0.00 372.16 1 Rake::Application#top_level
372.16 0.00 372.16 1 Rake::Application#run_with_threads
372.16 0.00 372.16 1 Rake::Application#invoke_task
372.16 0.00 372.16 3 Rake::Task#invoke
372.16 0.00 372.16 7 Rake::Task#invoke_with_call_chain
372.16 0.00 372.16 34 MonitorMixin.mon_synchronize
372.16 0.00 372.16 5 Rake::Task#execute
372.00 0.05 371.96 7498 Class#new
371.95 0.00 371.95 7 TSort.tsort_each
371.95 0.00 371.95 7 TSort.each_strongly_connected_component
371.94 0.01 371.93 321 TSort.each_strongly_connected_component_from
371.89 0.00 371.89 5 Rake::Task#invoke_prerequisites
371.87 0.00 371.87 1 Rails::Application#require_environment!
371.87 0.00 371.87 1 Rails::Application#initialize!
371.87 0.00 371.87 1 Rails::Initializable.run_initializers
371.83 0.02 371.81 102 BasicObject#instance_exec
371.66 0.00 371.66 89 Rails::Initializable::Initializer#run
370.71 0.01 370.70 51 BasicObject#instance_eval
370.61 0.00 370.61 30 ActiveSupport.execute_hook
370.58 0.00 370.58 7 ActiveSupport.run_load_hooks
369.39 0.00 369.39 38 ActiveSupport.on_load
369.35 0.00 369.35 1 Sprockets::Manifest#initialize
369.35 369.35 0.00 2 SecureRandom.hex
4.76 0.00 4.76 1 Rake::Application#load_rakefile
4.76 0.00 4.76 1 Rake::Application#raw_load_rakefile
4.76 0.00 4.76 1 Rake.load_rakefile
4.10 0.00 4.10 1 Gem::ExecutableHooks.run
3.53 0.00 3.53 106 Kernel.require
2.88 0.00 2.88 1 Noexec#check
2.88 0.00 2.88 1 Noexec#setup
2.42 0.00 2.42 1 Noexec#candidate?
1.87 0.02 1.84 144 Gem::Specification.load
1.69 0.02 1.67 2 Bundler.load
1.62 0.03 1.59 2 Bundler.definition
1.55 0.09 1.45 1635 Array#map
1.53 0.02 1.50 1 Bundler::Definition.build
1.48 0.00 1.48 1 Bundler::Dsl.evaluate
1.41 0.00 1.41 1 Bundler.require
1.41 0.00 1.41 1 Bundler::Runtime#require
1.32 0.00 1.32 2 Gem::Specification.each
1.32 0.00 1.32 3 Gem::Specification._all
Over 3 minutes per call to securerandom (it turns out on Virtual machines - my CI server, my staging server (self hosted) and my production box (Linode hosted) that entropic data is low in terms of volume, you can cat /dev/random and it runs out of data pretty fast, /dev/urandom is not affected)
So I did some research and found I could force the JVM to use urandom
( -J-Djava.security.egd=/dev/urandom) the timing of securerandom becomes perfectly good.
one thing I noticed though, if it was left for a while the /dev/random buffer had enough entropy backed up to be able to satisfy securerandom immediately for the first few calls.
I use securerandom a fair amount for generating UUIDs so it's really crippling my app, I have the option workaround to use urandom for now, but I bet a lot of people won't dig that far into it, assuming their app (that can take up to 8 minutes to start in my case) is simply crashing on jRuby or that the VM they use hasn't got the horsepower for jRuby.