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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4