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.
Mike H. (Guest)
on 2008-11-19 17: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 H.
Program Manager, Collaborative Software Initiative
removed_email_address@domain.invalid
http://www.csinitiative.com

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

    http://xircles.codehaus.org/manage_email
Mike H. (Guest)
on 2008-11-20 04: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 H.
Program Manager, Collaborative Software Initiative
removed_email_address@domain.invalid
Portland, Or 97258
http://www.csinitiative.com


Mike H. 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 H.
> Program Manager, Collaborative Software Initiative
> removed_email_address@domain.invalid
> http://www.csinitiative.com
>

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

    http://xircles.codehaus.org/manage_email
Ikai L. (Guest)
on 2008-11-20 04: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 H." <removed_email_address@domain.invalid> wrote:

> removed_email_address@domain.invalid
>> 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
>> removed_email_address@domain.invalid
>> 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
Mike H. (Guest)
on 2008-11-20 06: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 L. 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
Albert R. (Guest)
on 2008-11-20 22:08
(Received via mailing list)
On Thu, Nov 20, 2008 at 3:17 AM, Ikai L. <removed_email_address@domain.invalid> 
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 R.

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

    http://xircles.codehaus.org/manage_email
AD (Guest)
on 2008-11-20 23: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 R.
Ikai L. (Guest)
on 2008-11-22 02: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
)
Charles Oliver N. (Guest)
on 2008-11-22 05: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 L. 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
Charles Oliver N. (Guest)
on 2008-11-22 05: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 N. 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 R.
>>         >  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.