16 Oct, 2011, Silenus wrote in the 1st comment:
Votes: 0
Hello,

I was wondering what would be a good application to benchmark rails with? Do you have some idea of this?

Regards,

Carter.
28 Oct, 2011, Runter wrote in the 2nd comment:
Votes: 0
What do you want to benchmark? Most people only care about requests per second in production when compared to other frameworks. Generic software benchmarking applications might get some numbers, but I personally wouldn't find any use at all in these numbers.
01 Nov, 2011, Kelvin wrote in the 3rd comment:
Votes: 0
In the MUD context, you're very unlikely to run into performance issues unless you're doing something really silly. Pick the language you like the most and just go with it. If that's Ruby, pick up your Rails and run.
01 Nov, 2011, Runter wrote in the 4th comment:
Votes: 0
I wouldn't use rails for a mud at all. And even if you're just looking for a web-server… Rails can do it, but that's using a sledge hammer to crack a walnut.

Depending on your goals for your mud it may be appropriate just to write the entire thing in raw Ruby and use sinatra, padrino, or rack where a web server may or may not be required.
06 Nov, 2011, Silenus wrote in the 5th comment:
Votes: 0
Hi Runter,

I am curious whether you had any recommendations application wise for testing rails performance and how to load the rails system? I am curious how difference flavors of Ruby perform under different loads.

Regards,

Carter.
07 Nov, 2011, Runter wrote in the 6th comment:
Votes: 0
Silenus said:
Hi Runter,

I am curious whether you had any recommendations application wise for testing rails performance and how to load the rails system? I am curious how difference flavors of Ruby perform under different loads.

Regards,

Carter.


Firstly, there's really only 2 options (3 if you count 1.8 vs 1.9) for running rails. Jruby and Cruby (MRI and YARV). Technically they all strive for being able to ruby rails, but those are the only two that are really ready for prime time. There's tons of attempts at general benchmarks between the 3 for rails, they're not at all clear or really that useful, though. There's some certain facts, though. Jruby is much slower to start up. Cruby gets the critical updates first. Cruby has more compatibility for libraries. Jruby has a more mature (and to some, trusted) virtual machine.

There's others that are interesting, like Rubinius. On their website they claim "We are currently at a 93% RubySpec pass rate and growing everyday." That's something they created for judging their own compatibility, so I'd assume they're being gracious towards themselves…and 93% just isn't good enough, really. The maglev implementation just reached 1.0 this week. They're looking great, but I don't know how viable they are yet for rails, either.

The real problem with the performance testing is it swings widely from use-case to use-case and from specific code to specific code. If we consider most benchmark applications they run a lot of well known and structured algorithms. It's very difficult to do this with a framework like rails. Sure, we can throw in a hello world route and hit it over and over. But this isn't really that useful, other than maybe to know how many requests per second we could get in an open sprint.

So what web app developers do generally is test the parts of the whole (like ruby, and rack, and core parts of rails). How they perform as a whole becomes more difficult to discern. Beyond that we test our specific application for bottlenecks. Here's an official documentation for doing that.
http://guides.rubyonrails.org/performanc...
15 Nov, 2011, Silenus wrote in the 7th comment:
Votes: 0
Hi Runter,

This maybe a rather basic question but what is the difference between the two flavours of cruby? I did notice some mention recently of a 2.0.0 release. Is this the future direction of ruby?
15 Nov, 2011, Runter wrote in the 8th comment:
Votes: 0
Silenus said:
Hi Runter,

This maybe a rather basic question but what is the difference between the two flavours of cruby? I did notice some mention recently of a 2.0.0 release. Is this the future direction of ruby?


Yeah, the 2.0 release development recently officially started. It's based on the 1.9 interpreter. Basically they should have called it 2.0 when they adopted yarv as 1.9, but there were political considerations. The leap in technology from 1.9 to 2.0 is less than 1.8 to 1.9 by far. It's made for a rather confusing situation with patches to the 1.8 branch being patches to make the old interpreter compatible with the 1.9 changes. There is a community still using 1.8, but it's shrinking day by day as major services get on board with 1.9 as a defacto choice in what they provide. With good reason. 1.9 really improves the viability of ruby as performant.

If you really want to look at something interesting check out rubinius and maglev. I believe twisol is developing some type of lua interpreter on top of rubinius. I love the idea of the ruby language implemented in Ruby. It makes changing it at the lowest level very reasonable, and the various components of the language (like garbage collection) more modular by virtue of the concept.
15 Nov, 2011, Silenus wrote in the 9th comment:
Votes: 0
Thanks Runter.
16 Nov, 2011, Tyche wrote in the 10th comment:
Votes: 0
The are 3 versions of the MRI Ruby, 1.8.6, 1.8.7 and 1.9.x, maintained by 3 different groups. Odd number releases are development branches, 1.9 is the development branch for Ruby 2.0. 1.8.x branches are interpreted. The 1.8.7 added some class and syntax changes from Ruby 2.0 which broke compatibility, so many refused to use it. Ruby 2.0 generates intermediate bytecode that runs on a VM (based on YARV). It supports unicode, many syntax changes and hundreds of class/method changes and additions. Ruby 2.0 has been in development for at least 6 years. When Ruby 1.9 branch will become stable Ruby 2.0 no one knows, as every year for the last 6 years, the developers announce it will done next year. The development problems are very similar to what happened to Perl 5 on the way to Perl 6. Endless out of control modifications to syntax. I give Ruby 1.9.x branch a try every year, report a crap load of bugs and crashes, then shelf it. IMNSHO, It's not neither stable nor suitable for production use. Ruby 2.0 is a language that bit rots in weeks and months, rather than years. YMMV
16 Nov, 2011, Runter wrote in the 11th comment:
Votes: 0
My experience with ruby 1.9.2 and ruby 1.9.3 is that they're very stable.
16 Nov, 2011, Silenus wrote in the 12th comment:
Votes: 0
Are you aware of what changes are being made between the 1.9.3 and the 2.0.0 release? My sense is the big syntax change between MRI and YARV is the dynamic scoping of blocks. I am not sure I understand this change since one can if I understand correctly convert blocks into say methods- would this imply one can have odd scoping issues?
16 Nov, 2011, Runter wrote in the 13th comment:
Votes: 0
The ones semi-confirmed are keyword arguments for methods, bytecode import/export, refinements (to solve monkey patching), and standard library being moved to gems.

Refinements have been controversial because their proposed implementation wasn't exactly efficient. The keyword arguments thing is sort of just an easier way to do something you could have done with a hash pretty easily.
17 Nov, 2011, Silenus wrote in the 14th comment:
Votes: 0
I was examining the source code as well. I am wondering how far they will push things implementation wise between 1.9.3 and 2.0.0. I am still rather curious if the ruby team will accept patches against 1.9.3
0.0/14