Forum: JRuby 1.1.3 & 1.1.5 nearly identical benchmark wit Rails app ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bfe866459e40cb7392194ab08fcb5dea?d=identicon&s=25 Mike Herrick (mherrick66)
on 2008-11-19 16:38
(Received via mailing list)
I'm doing some tuning of our JRuby/Rails app, TriSano (www.trisano.org).

We were still on 1.1.3 so one of the first things I did was upgrade to
1.1.5.

Interestingly? the benchmarks are virtually identical between 1.1.3 and
1.1.5.

See: https://trisano.csinitiative.net/wiki/TriSanoBenchmarks

Specifically:
https://trisano.csinitiative.net/wiki/Nov8Benchmar...
https://trisano.csinitiative.net/wiki/Nov8Benchmar...

The benchmarks are very simple - I'm just using httperf to exercise
certain aspects of the application.

To upgrade to JRuby 1.1.5 with a webapp all you need to do is replace
jruby-complete.jar which I did.

Is it plausible that there would be virtually no difference in rails
apps between 1.1.5 and 1.1.3? Or perhaps I missed something and I'm
really just testing 1.1.3 2x? Seems unlikely as here is what Tomcat has
in its directory:

:~/opt/apache-tomcat-6.0.14/webapps/trisano/WEB-INF/lib$ ll
total 8.7M
-rw-r--r-- 1 mike mike  560 2008-11-18 20:04 utilities.rb
-rw-r--r-- 1 mike mike  982 2008-11-18 20:04 library_element_cache.rb
-rw-r--r-- 1 mike mike 8.4M 2008-11-18 20:04 jruby-complete-1.1.5.jar
-rw-r--r-- 1 mike mike 1.4K 2008-11-18 20:04 form_element_cache.rb
-rw-r--r-- 1 mike mike  288 2008-11-18 20:04 extend_better_nested_set.rb
-rw-r--r-- 1 mike mike 2.8K 2008-11-18 20:04 cacheable_tree.rb
-rw-r--r-- 1 mike mike 1.3K 2008-11-18 20:04 blankable.rb
-rw-r--r-- 1 mike mike 226K 2008-11-18 20:04 jruby-rack-0.9.2.jar
drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 tasks
drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 soundex
drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 selenium_grid
drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 mmwr
drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 export
drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 active_record


Thanks,

Mike

Mike Herrick
Program Manager, Collaborative Software Initiative
mike@csinitiative.com
http://www.csinitiative.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Bfe866459e40cb7392194ab08fcb5dea?d=identicon&s=25 Mike Herrick (mherrick66)
on 2008-11-20 03:03
(Received via mailing list)
Never mind - I was using Hudson to do this and was using bits I didn't
realizes I was using.

Anyway, 1.1.5 is faster. I need to clean this up a lot, but here are the
prelim results:

https://trisano.csinitiative.net/wiki/Nov19Benchma...

Mike Herrick
Program Manager, Collaborative Software Initiative
mike@csinitiative.com
Portland, Or 97258
http://www.csinitiative.com


Mike Herrick wrote:
> Specifically:
> apps between 1.1.5 and 1.1.3? Or perhaps I missed something and I'm
> -rw-r--r-- 1 mike mike 2.8K 2008-11-18 20:04 cacheable_tree.rb
> Thanks,
>
> Mike
>
> Mike Herrick
> Program Manager, Collaborative Software Initiative
> mike@csinitiative.com
> http://www.csinitiative.com
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
F7e175b37a4c69709ef75c28792f2b32?d=identicon&s=25 Ikai Lan (Guest)
on 2008-11-20 03:18
(Received via mailing list)
Mike,

What might be an interesting benchmark would be the performance of JRuby
and
Rails 2.2. One of the best things about Rails 2.2 is the threadsafe
mode,
where the most annoying bottleneck of Rails (concurrency) is handled
beautifully by JRuby. I've been running 2.2 RC1 in a test environment on
JRuby on Rails on Glassfish and it's pretty spiffy. My memory usage is
down
50% because now I am running 1 instance of threadsafe Rails (>2.2)
rather
than 10 completely isolated instances (2.1). It handles the load pretty
well, and the only real place where it breaks down is if HTTPerf bangs
on it
with too many instances and MemCache starts giving me strange outputs.

I'm probably going to roll into production with this in the next few
weeks
or so.


Ikai


On 11/19/08 6:01 PM, "Mike Herrick" <mike@csinitiative.com> wrote:

> mike@csinitiative.com
>> Interestingly? the benchmarks are virtually identical between 1.1.3 and
>>
>> -rw-r--r-- 1 mike mike  560 2008-11-18 20:04 utilities.rb
>> drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 mmwr
>> mike@csinitiative.com
>> http://www.csinitiative.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Bfe866459e40cb7392194ab08fcb5dea?d=identicon&s=25 Mike Herrick (mherrick66)
on 2008-11-20 05:20
(Received via mailing list)
Ikai,

Yes it will be a great benchmark - we are still on Rails 2 & need to
upgrade.

We are certainly excited to do so. Hopefully we can do it soon.

Nice to hear you are having positive results already. Threading is
obviously a place that JRuby can really shine.

Mike


Ikai Lan wrote:
> with too many instances and MemCache starts giving me strange outputs.
>> Never mind - I was using Hudson to do this and was using bits I didn't
>> Portland, Or 97258
>>> 1.1.5.
>>> To upgrade to JRuby 1.1.5 with a webapp all you need to do is replace
>>> -rw-r--r-- 1 mike mike  982 2008-11-18 20:04 library_element_cache.rb
>>> drwxr-xr-x 2 mike mike 4.0K 2008-11-18 20:05 export
>>> http://www.csinitiative.com
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Bc1f306c4526643e6524030285884318?d=identicon&s=25 Albert Ramstedt (Guest)
on 2008-11-20 21:08
(Received via mailing list)
On Thu, Nov 20, 2008 at 3:17 AM, Ikai Lan <ilan@linkedin.com> wrote:

> My memory usage is down
> 50% because now I am running 1 instance of threadsafe Rails (>2.2) rather
> than 10 completely isolated instances (2.1). It handles the load pretty
> well, and the only real place where it breaks down is if HTTPerf bangs on it
> with too many instances and MemCache starts giving me strange outputs.

So, you use memcache on a jruby on rails stack? Could I ask what client
you
are using? Since memcache-client uses Timeout, we've had some issues
running
it - when a node dies we get errors instead of it failing and
switching to another node.
So we are going to wrap some java memcache lib instead, and perhaps you
have
done this already? If so, if you can share any code or insights, it
would be greatly
appreciated!

Albert Ramstedt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
F15fdc7cb2e911b3808837f2be244add?d=identicon&s=25 AD (Guest)
on 2008-11-20 22:27
(Received via mailing list)
Albert,

 We use the normal memcache-client gem and in fact had to shutdown the
memcache instances because of a caching bug.  I didnt see any major
issues
when doing this on Jruby 1.1.4 Rails 2.1.2

Adam

On Thu, Nov 20, 2008 at 3:08 PM, Albert Ramstedt
F7e175b37a4c69709ef75c28792f2b32?d=identicon&s=25 Ikai Lan (Guest)
on 2008-11-22 01:30
(Received via mailing list)
So the ships have been burned. The serious production issue we've been
seeing with blocked threads is directly related to memcache-client gem
doing
IO.

Based on some suggestions from coworkers, it looks like I'm going to
create
a light wrapper around Whalin that looks like memcache-client:

http://whalin.com/memcached/

Does anyone see any red flags with this approach?

The thread dump is below my signature.

Ikai

"httpSSLWorkerThread-8080-4" daemon prio=10 tid=0x08d4c000 nid=0x2354
waiting for monitor entry [0xaf1e9000..0xaf1efae0]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.jruby.util.io.ChannelStream.feof(ChannelStream.java:486)
    - waiting to lock <0xc7d06f90> (a org.jruby.util.io.ChannelStream)
    at org.jruby.util.io.OpenFile.checkWritable(OpenFile.java:128)
    at org.jruby.RubyIO.write(RubyIO.java:1004)
    at
org.jruby.RubyIO$i_method_1_0$RUBYINVOKER$write.call(org/jruby/RubyIO$i_meth
od_1_0$RUBYINVOKER$write.gen)

    at
org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:391)
    at
ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_mo
dules.polls.WEB_minus_INF.gems.gems.memcache_minus_client_minus_1_dot_5_dot_
0.lib.memcache.cache_get1328683_12495564.__file__(memcache.rb:550)

    at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:286
)

    at
org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:442)
    at
ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_mo
dules.polls.WEB_minus_INF.gems.gems.memcache_minus_client_minus_1_dot_5_dot_
0.lib.memcache.get32999431_12495564.rescue_1$RUBY$__rescue__(memcache.rb:209
)

    at
ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_mo
dules.polls.WEB_minus_INF.gems.gems.memcache_minus_client_minus_1_dot_5_dot_
0.lib.memcache.get32999431_12495564.__file__(memcache.rb)

    at
org.jruby.internal.runtime.methods.DefaultMethod.retryJITCall(DefaultMethod.
java:148)

    at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:138
)
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2008-11-22 04:48
(Received via mailing list)
I've already identified this problem, I believe. Uwe reported it on IRC
a few days after I arrived in Sweden, and I haven't had a chance to fix
it. But it will be in 1.1.5.

If you want to fix it yourself, remove the "synchronized" from
ChannelStream.feof. Done!

- Charlie

Ikai Lan wrote:
>
>     at org.jruby.RubyIO.write(RubyIO.java:1004)
>     at
> 
ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.memcache_minus_client_minus_1_dot_5_dot_0.lib.memcache.get32999431_12495564.__file__(memcache.rb)
>
>
>         >  well, and the only real place where it breaks down is if
>         So we are going to wrap some java memcache lib instead, and
>             http://xircles.codehaus.org/manage_email
>
>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2008-11-22 04:54
(Received via mailing list)
FYI: http://jira.codehaus.org/browse/JRUBY-3155

The fix is on trunk, but I reopened the bug until I can get a test
added.

Charles Oliver Nutter wrote:
>> So the ships have been burned. The serious production issue we've been
>> The thread dump is below my signature.
>>     at
>> org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:286)
>>
>>
>>     On Thu, Nov 20, 2008 at 3:08 PM, Albert Ramstedt
>>         >  well, and the only real place where it breaks down is if
>>         So we are going to wrap some java memcache lib instead, and
>>         To unsubscribe from this list, please visit:
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
This topic is locked and can not be replied to.