On Fri, Dec 19, 2008 at 6:26 AM, Charles Oliver Nutter < charles.nut...@sun.com> wrote:
> avishek.dasgupta wrote: > >> >> Charles Oliver Nutter-2 wrote: >> >>> Interesting numbers...I think we need more information, however, like >>> what version of JRuby you ran and a short description of how the application >>> works. There have been threading-related bottlenecks reported over time, but >>> we've solved many of those issues. >>> >>> Also 1.1.6 is coming out today, which includes a number of these fixes. >>> >>> - Charlie >>> >>> >> The JRuby version I used was 1.1.5 with Java 6 >> Additional VM arguments used were: >> -Xmx768M -Xms768M -Djruby.objectspace.enabled=false >> -Djruby.thread.pooling=true >> >> I got JRuby 1.1.6 and ran the application again and got these numbers: >> Threads JRuby Java >> ======================= >> 5 41.62 31.20 >> 10 77.04 31.45 >> 15 103.14 31.45 >> 20 126.24 31.41 >> 25 173.93 32.17 >> > > Ok, so there's improvement, but it still degrades pretty severely. If > possible, can you also try running with -Djruby.compile.fastest=true? It may > not work, but it does remove some overhead (highly experimental). > > If I were to venture a guess, it's possible there's lock contention slowing > things down (lost of concurrent lookups to synchronized resources somewhere? > probably relating to the Java objects antering the system?) or we've got a > single piece of data being mutated rapidly across threads (we found a > similar issue where a single static int was being incremented rapidly by > different threads, causing cache flushes to kill performance). We need to > put the clamps on your app and see what we can find... > > - Charlie > Just another guess: Maybe GC slows things down? Have you tried parallel GC?
