Some fellow name TAKAI Naoto has posted an interesting comparison of JRuby on Rails running under WEBrick versus running under AsyncWeb:
TAKAI Naoto compares WEBrick and AsyncWeb and a comical translation.
Although the numbers he shows for WEBrick seem *awfully* slow (4-6 seconds per request...we haven't been that slow since JavaOne running Rails in "development" mode) what's most interesting is the speed gains he gets from AsyncWeb: something like a five times improvement. If we assume there would be an improvement running a more recent JRuby (0.9.1 should be considerably faster than all previous versions) and running Rails in production mode...well, this thing starts to look real-world ready.
He has a link to a snapshot...I'm investigating that now and will update this post when I know more.
See also Takai's post about about JRuby on Rails running under AsyncWeb:
TAKAI Naoto running JRuby on Rails with AsyncWeb and translation.
These sorts of things show real promise...AsyncWeb scales extremely well and is built upon Java's NIO library. A new contender enters the Rails front-ending competition!
Update: Ok, I've spent five minutes looking at the code, and it's cooler than I thought. He's got AsyncWeb and JRuby on Rails wired together using Spring, and it's a trivial amount of code to do it...like less code than WEBrick. I hope he's able to get a release out for this soon.
Here's a direct link to his rails-asyncweb snapshot. Super cool.
Wednesday, October 18, 2006
JRuby on Rails: WEBrick vs AsyncWeb
Subscribe to:
Post Comments (Atom)
2 comments:
Hung: That day is today! We are cautious about saying "Rails is supported" since there are many test cases remaining that do not pass, but for most simple Rails apps, jruby script/server DOES work! Of course if you want ActiveRecord support, you need ActiveRecord-JDBC (gem install ActiveRecord-JDBC), but it works well enough today to start playing with.
What we really need is more folks running Rails aps and test cases and reporting bugs in our JIRA (google "jira jruby").
This is interesting. I would be interested to see how the performance of running it on top of AsyncWeb running of top of Grizzly
Might event gives better result :-)
-- Jeanfrancois
Post a Comment