<chrisseaton>
koochdog: it's the 'god object' of JRuby
shellac has quit [Quit: Computer has gone to sleep.]
Aethenelle has quit [Quit: Aethenelle]
Aethenelle has joined #jruby
Aethenelle has quit [Client Quit]
bjfish2 has quit [Quit: bjfish2]
tomjoro has quit [Remote host closed the connection]
<koochdog>
chrisseaton: I think I ended up narrowing down the issue... It looks like the getppid() is coming from Java JNR POSIX... I'm thinking that JNR might not support SPARC
<kares>
rails690_: yes hopefully its faster than MRI - in most cases but its not a general recipe
<kares>
I sure know ar under jruby with ar-jdbc is slower than plain ar under MRI
<donV>
Got a really small test case, so should be quick to determine if it is a bug or wrong expectation from me.
<rails690_>
kares: so do u think, even if its warmed up, the operations will be slower than MRI?
<rails690_>
MRI ar
<kares>
donV: yea except for AS :) ... will take a look - hopefully today
<kares>
rails690_: I do not think anything - I do not know your app :)
<donV>
rails690_: Micro benchmarks for us have JRuby from 20% slower to 100% faster looking at _one_ process/thread.
<rails690_>
kares: i switched to jruby for 2 reasons: 1. performance, 2: portability (.war/.jar)
<donV>
rails690_: The big benefit for us comes from multi-threading the requests.
<rails690_>
donV: interesting, where could i get into that with rails? Jobs?
<donV>
rails690_: The portability of JRuby is so great, I have nearly forgotten about it :)
<kares>
rails690_: but I'm guessing unless you're doing smt exotic or have some crazy code in the path request times should match up MRI ... after a warmup period
<kares>
on production
<rails690_>
kares: I see.. sometimes i have an opeartion on 1000 records..but im planning to make that into a sidekiq or resque job
<donV>
rails690_: Puma (and some others) serve the requests using multiple threads by default, so you should get the benefit out of the box.
beawesomeinstead has quit [Ping timeout: 250 seconds]
<rails690_>
donV: i see.. when it comes to production, is there a way to "pre" warm it up?
<donV>
rails690_: In production, _full_ warmup is just about 20000 requests for us.
tomjoro has joined #jruby
<kares>
rails690_: do not worry about it much - rather make sure your code is thread-safe
<rails690_>
kares: how can i ensure my code is thread-safe?
<kares>
:)
beawesomeinstead has joined #jruby
<donV>
rails690_: Yeah, I agree with kares
<donV>
rails690_: Rails code is most often thread safe.
<rails690_>
donV: 20,000 requests, what if I use a script to make those requests in the beginning
<donV>
rails690_: Just don’t use global state inside your own code, like changing global variables or changing values pointed to by constants.
<rails690_>
donV: ok i dont do that anyways
<donV>
rails690_: Performing 20.000 requests in the beginning will make the subsequent requests fast :)
<rails690_>
donV: ok good
<rails690_>
are there any optimized settings I should use inside of JRUBY_OPTS?
<donV>
Most often we only do like 1000
<rails690_>
with Java 8
<donV>
-J-Xmx1G where “1G” is the amount of memory you can give your app. Generally more is better :)
<donV>
rails690_: We have apps using up to 4G.
<donV>
rails690_: default is 500M
<rails690_>
donV: ok thank you, is that all? i should also disable invokedynamics right?
<donV>
rails690_: We have stayed away from invokedynamic, but it can speed things up considerably.
<rails690_>
donV: but i heard in rails it slows things down
<donV>
We used it early when it first came out, and memory use was higher and the warmup even longer.
<GitHub2>
jruby/master a5c9372 kares: extract unsupported last arg detection into helper and only warn is hash not empty
<GitHub2>
jruby/master b7f7d31 kares: [build] latest jar plugin seems fine and gets a bit faster on times
<donV>
rails690_: but is many cases it was faster eventually.
<donV>
rails690_: We have not tried it for over a year, so things may be different.
<rails690_>
donV: not tried in over a year, oh boy
<donV>
rails690_: indy, that is.
<rails690_>
donV: should i use jruby-9.0.0.0 or jruby-1.7.x?
<kares>
rails690_: donV its getting better (including JRuby's support) these days ... would say maybe for a next 9.1 release it might be worth a re-try
<kares>
rails690_: use 9.0.5.0
<kares>
unless you want to be stucked on MRI 1.9.3 than use 1.7
<rails690_>
kares: and the warbler 2.x dev is stable enuf to use for jruby 9.0.5.0?
<rails690_>
kares: nope i need ruby 2.2
<donV>
rails690_: We use 9.0.5.0 except we got a critical bug with autoload with it. Our fallback is 9.0.1.0.
<kares>
rails690_: than you do not have a choice - not sure if stable warbler handles 9K
<rails690_>
donV: a critical bug with autoload --> is that something i should be concerned about using jruby on rails?
<donV>
kares: We will definitely try indy with 9.1.0.0.
<donV>
rails690_: The bug has only appeared in non-rails applications. Rails is running absolutely fine for us with JRuby 9.0.5.0.
<rails690_>
donV: ok cool
<donV>
kares: Any chance you could look at the autoload issue? I have absolutely no idea where to start.
<donV>
kares: Or maybe I should just bug enebo and headius about it :)
<rails690_>
donV: so is that it, besides the ram allocation for JRUBY_OPTS?
<rails690_>
donV: in regards to optimizations
<rails690_>
i hope warbler works with jruby 9.x , because i really need the portability
<donV>
rails690_: Here are our current standard JRuby on rails startup options:
<donV>
rails690_: The GC_OPTS are for monitoring memory use and GC activity.
<donV>
rails690_: “—server” is important. This is with Java 8. We will be looking at using Java 9 any day now :)
<rails690_>
i dont know if u guys would know this however im just asking in case, i just installed jruby-9.0.5.0 using rvm, how do I port my gems from jruby-9.0.0.0 to the new jruby-9.0.5.0 installation?
<rails690_>
donV: thank you
<donV>
rails690_: We just use Bundler and reinstall, but you can use global gemsets with RVM.
<rails690_>
donV: ok thanks
<kares>
donV: yep will look as I'm looking into some autoload/require things as well
<donV>
kares: Thank you so much!
<donV>
rails690_: “rvm use jruby-9.0.1.0@global” install the gems, then “rvm use jruby-9.0.5.0@global”
<donV>
rails690_: Then you have the same gems.
<donV>
rails690_: You can of cource use a different gemset than “global”.
<rails690_>
donV: ok got it, thanks
<donV>
Well, got to go to work. Online in half an hour again :)
donV has quit [Quit: donV]
donV has joined #jruby
<donV>
I’m back!
mberg has quit [Ping timeout: 240 seconds]
atambo has joined #jruby
atamb0 has quit [Ping timeout: 256 seconds]
mberg has joined #jruby
rsim has quit [Quit: Leaving.]
mberg is now known as Guest97970
<rails690_>
donV: i have a question about the RAM allocation
<rails690_>
donV: if i want to allocate 4GB, how much RAM should the physical computer itself have?
balo has quit [Remote host closed the connection]
balo has joined #jruby
donValentin has joined #jruby
<rails690_>
donV: question #2, if u warm up the application, does it have to warm up again every time you stop/start it?
<donValentin>
rails690_: Hi! Just saw your question. Yes, warmup is not persistent in any way.
<donValentin>
rails690_: You have to warm up on every JRuby startup.
<rails690_>
donValentin: on every JRuby startup, but does that mean App startup?
<rails690_>
donValentin: JRuby startup, i assume that means restarting the computer or does it mean restarting the app?
<donValentin>
rails690_: Ussually that means app startup.
<rails690_>
donValentin: aw thats kind of sad
<rails690_>
donValentin: ok what about the ram question
<rails690_>
donValentin: but i dont think its that big of a problem if i just run a background job for making 20,000 requests everytime the app starts
<donValentin>
rails690_: I missed the RAM question. What was it?
<rails690_>
if i want to allocate 4GB, how much RAM should the physical computer itself have?
<rails690_>
donValentin: if i want to allocate 4GB, how much RAM should the physical computer itself have?
<donValentin>
Firstly: You should measure how much your app actually uses. Most of our apps use below 1G, some 2G, one 4G.
<donValentin>
When you monitor the memory usage, you will see “RESident” memory larger than the HEAP size you set. You need more physical memory that that value :)
<donValentin>
-Xmxnn sets MAX HEAP size, but that does not mean the app actually uses that much memory. The limit is VIRTual memory, and does not have to be covered by physical memory, but if you go over, the system will start paginf to disk, which usually is unacceptably slow.
<kares>
donValentin: if you prepend '::' ... include ::AutoloadModule (ModuleC) it works
rails690_ has quit [Read error: Connection reset by peer]
<kares>
maybe that its the correct behavior - not sure yet
donV has joined #jruby
<kares>
the Java class seems to not play a role does it ?
rails690 has joined #jruby
<kares>
oh it does ... just figured it out - ignore the prev comment
<vladimir_>
Can anybody clarify if jnr or jnr-ffi is a good to call dynamically linked C functions from within JVM?
donV has quit [Quit: donV]
pawnbox has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
jensnockert has quit [Remote host closed the connection]
jensnockert has joined #jruby
chore has joined #jruby
jensnockert has quit [Remote host closed the connection]
<GitHub117>
[jruby] chrisseaton closed issue #3414: [Truffle] timezone related bugs manifesting in activesupport tests https://git.io/vWCF3
<GitHub126>
[jruby] headius closed issue #3672: JRuby is super-slow to execute a big and trivial case-when statement https://git.io/vg52J
pawnbox has quit [Remote host closed the connection]
<GitHub25>
[jruby] headius pushed 1 new commit to ruby-2.3: https://git.io/vg5Nn
<GitHub25>
jruby/ruby-2.3 094bbef Charles Oliver Nutter: Merge remote-tracking branch 'origin/master' into ruby-2.3...
pawnbox has joined #jruby
jensnockert has joined #jruby
pitr-ch has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
jensnockert has quit [Ping timeout: 248 seconds]
vladimir_ has quit [Remote host closed the connection]
<chore>
I'm attempting to use jruby in a maven build via the gem-maven-plugin. This plugin has a supportNative parameter that has been deprecated. When setting this parameter to true and using version 9.0.5.0 I receive "NotImplementedError: C extensions are not supported". I have searched for information and it appears that older version of jruby suppor
<chore>
ted C extensions. Can jruby 9 support C extensions or native gems?
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub99>
[jruby] TheKidCoder opened issue #3673: Thread Crashing with Puma on 9.x https://git.io/vgdOM
shellac has joined #jruby
rsim has quit [Quit: Leaving.]
arbox has quit [Ping timeout: 240 seconds]
<chore>
I'm attempting to use jruby in a maven build via the gem-maven-plugin. This plugin has a supportNative parameter that has been deprecated. When setting this parameter to true and using version 9.0.5.0 I receive "NotImplementedError: C extensions are not supported". I have searched for information and it appears that older version of jruby suppor
<chore>
ted C extensions. Can jruby 9 support C extensions or native gems?
<nirvdrum>
chore: JRuby 1.7.x can install C extensions, but they never ran terribly well. The code for that was thus removed for JRuby 9k. You can install gems that use FFI or have native Java extensions.