1.1.3 & 1.1.5 nearly identical benchmark wit Rails app?


#1

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/Nov8BenchmarkJrubyVersion113
https://trisano.csinitiative.net/wiki/Nov8BenchmarkJrubyVersion115

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

#2

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/Nov19BenchmarkJrubyVersion115

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

#3

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

#4

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

#5

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.


#6

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

#7

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
)


#8

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

#9

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