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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
