Struts vs RoR

Rails
1

hi,

I recently attended one of the ruby meetings that we have in my city.
There one of the speaker said that google,amazon … are working on RoR
but still the performance of RoR is not at par with J2EE others…

he meant that though google,amazon working o it they will not bring it
as
front applications only parts
the reason ruby is slow in comparison to other languages…
and in real time systems also it wont be used…

now the concern is i have to implement a project management web based
application and we have to
resolve the issue what technology to use.

So is it so that RoR is slow in performance(relatively) and to boost it
to a
level better hardware is needed.

any suggestions

Thanks in advance

warm regards
gaurav v bagga

2

On 7/20/06, gaurav bagga [email protected] wrote:

now the concern is i have to implement a project management web based
application and we have to
resolve the issue what technology to use.

So is it so that RoR is slow in performance(relatively) and to boost it to
a level better hardware is needed.

In most cases, no.

any suggestions

Get on with creating your application and don’t waste time getting
into the whole which language is faster debate. For the average web
app, the difference in speed between different platforms is simply not
going to be noticable enough by your users to make it a major deciding
factor in which platform to use. Much more important is how
productive you will be, what features you need, etc… There are
always ways to increase performance if you need to do so.

3

I’ve never heard of J2EE being used as the standard for performance!
Usually it’s the opposite.

Joe

4

Google and Amazon have concernes about the performance of RoR because
they are two of the most visited websites in the world. You won’t even
notice a difference.
-Nathan

5

On 7/21/06, gaurav bagga [email protected] wrote:

I recently attended one of the ruby meetings that we have in my city.
There one of the speaker said that google,amazon … are working on RoR
but still the performance of RoR is not at par with J2EE others…

Maybe. But you should also consider that in order to run your
application a few seconds faster, you may wind up taking several extra
weeks or months to implement it since J2EE is nowhere near as
productive as Rails.

he meant that though google,amazon working o it they will not bring it as
front applications only parts
the reason ruby is slow in comparison to other languages…
and in real time systems also it wont be used…

Google and Amazon are totally different beasts from normal web sites.
The kind of things they need to worry about are probably things that
you would never encounter in ‘normal’ use. Making your decision based
on this is a bit like saying that because the USA went to the moon,
you are going to use a rocket to climb Mount Everest. Totally not
necessary.

– G.

6

interesting replies

i appreciate efforts and thank u all for ur comments

hope i can use ur replies to convience people here with me

7

Just carry on with ROR developement.You won’t have any problem.

Goodluck
Dibya

8

gaurav bagga wrote:

now the concern is i have to implement a project management web based
application and we have to
resolve the issue what technology to use.

So is it so that RoR is slow in performance(relatively) and to boost
it to a level better hardware is needed.

Just throwing my 2c in here like everyone else. Performance is relative.
How much performance do you really need? An average Rails page on my
server (a rather simple single-CPU XEON) stats out to about 60-70
reqs/second maximum against that particular server. That means I could
handle up to 3-4000 page views per minute, no sweat. By distributing
load, I can achieve much better numbers.

The question is whether you wish to pay for simple commodity hardware,
or pay for unhappy developers taking twice as long to create the
application. It really is as simple as that.

And also - who says J2EE is faster? I believe that’s as much hype as
anything.

Regards,
Henning K.
Rails Foundry
http://railsfoundry.com/

9

On 7/21/06, Henning K. [email protected] wrote:

And also - who says J2EE is faster? I believe that’s as much hype as
anything.

Ruby, the language, is dog slow, while Java runs about as fast a s
possible.

Also, Active Record is somewhat primitive, lacking support for
prepared statements, for instance. This means your app and database
are spending a fair amount of resources on parsing and planning the
same queries repeatedly.

Java is superior in other regards as well, for instance when it comes
to distributed transaction support and messaging.

That said, I generally prefer rails for anything that doesn’t require
massive throughput or distributed transactions…

Isak

10

Is there any data to backup the claim that Ruby is “dog slow”? I’ve not
experience bad performance.

As for repeated repeated queries, one word - caching.

Joe

11

Is there any data to backup the claim that Ruby is “dog slow”? I’ve not
experience bad performance.

As for repeated read queries, one word - caching.

Joe

12

On 7/22/06, Joe [email protected] wrote:

Is there any data to backup the claim that Ruby is “dog slow”? I’ve not
experience bad performance.

There are plenty of benchmarks out there, try google. Ruby generally
ranks close to the bottom, often beat by an order of magnitude.

People often overrate execution speed, though. If your application
isn’t CPU bound and computationally expensive, language speed just
isn’t an issue.

Also, Active Record is somewhat primitive, lacking support for
prepared statements, for instance. This means your app and database
are spending a fair amount of resources on parsing and planning the
same queries repeatedly.

As for repeated repeated queries, one word - caching.

Should perhaps have written ‘similar queries’ instead of ‘same’, but
think I wrote enough to convey the gist on prepared statements.

What data you query for may be different, but the parsed query and its
execution plan are cached, improving performance a lot when you do hit
the db.

Isak

13

Isak H. wrote:

On 7/22/06, Joe [email protected] wrote:

Is there any data to backup the claim that Ruby is “dog slow”? I’ve not
experience bad performance.

There are plenty of benchmarks out there, try google. Ruby generally
ranks close to the bottom, often beat by an order of magnitude.

People often overrate execution speed, though. If your application
isn’t CPU bound and computationally expensive, language speed just
isn’t an issue.

Here’s PHP vs. Ruby:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=php

Ruby is less than 5% slower than PHP, on average. And Ruby does a lot
better on memory use.

Ruby vs. Perl is just slightly worse:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=perl

Going through the scripting language comparisons, it appears Ruby is no
less than about 3-8% worse in CPU use than the rest. In the range, it
makes little difference in my mind. And as the tests show, if you really
need much better performance, you’ll need to use compiled languages.

Joe

14

Isak H. wrote:

On 7/22/06, Joe [email protected] wrote:

Is there any data to backup the claim that Ruby is “dog slow”? I’ve not
experience bad performance.

There are plenty of benchmarks out there, try google. Ruby generally
ranks close to the bottom, often beat by an order of magnitude.

I always doubted on the obectivity of those banchmarks, how can you
compare two languages which are so far one from the other, what I means
is that benchmarking require the two applications to be comparable,
right ?
How can you take a java application and a Ruby application and say: they
are the same I will now compare them ?

Here is a story from my own experience: I wrote a little java
application some times ago to parse comments from the source files of a
C++ application and generate a html documentation (I know it already
exists by I needed a very specific thing), later I then discovered Ruby
and rewrote the application as a Ruby script. The comparaisons in speed
between both gave Ruby as a clear winner in my case, all I want to say
here is that banchmarks depends clearly on the way applications are
coded, or what they do and how they do it (it is event worse if you use
very specific language optimization in one application but not in the
other), etc…

What I know is that I love to code in Ruby but in the other side I
always hated java and hopefully will never to write any line of it ^^
Productivity is so high when coding in Ruby compared to any other
language I worked with, and I don’t only speak about Rails, even in pure
Ruby.

People often overrate execution speed, though. If your application
isn’t CPU bound and computationally expensive, language speed just
isn’t an issue.

Also, Active Record is somewhat primitive, lacking support for
prepared statements, for instance. This means your app and database
are spending a fair amount of resources on parsing and planning the
same queries repeatedly.

As for repeated repeated queries, one word - caching.

Should perhaps have written ‘similar queries’ instead of ‘same’, but
think I wrote enough to convey the gist on prepared statements.

What data you query for may be different, but the parsed query and its
execution plan are cached, improving performance a lot when you do hit
the db.

Isak

15

How about support for prepared statements ?

On 7/23/06, Joe [email protected] wrote:

isn’t an issue.
Going through the scripting language comparisons, it appears Ruby is no
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

–
rm -rf / 2>/dev/null - http://null.in

“Things do not happen. Things are made to happen.” - JFK

16

On Jul 22, 2006, at 2:09 PM, Dan K. wrote:

Why bother? The whole point of ActiveRecord is to insulate the
programmer from having to write SQL in most (now almost all)
cases. Prepared Statements could be implemented as an optimization
of how AR connects with the database, but have you seen any apps
that are are not scaling because AR is speaking plain SQL?

Prepared Statements aren’t even necessarily faster.
How do employers view the UCI Cybersecurity Bootcamp? - JGuru

That sounds like a Java driver issue to me.

Back in 1998, I was architect on a large scale Perl project
during Web 1.0.

We converted the application from fully formed SQL to placeholders
and the difference in performance was dramatic, though mostly in
terms of DB machine utilization, not so much application performance
via the browser.

That said, we were able to scale the application far higher with
prepared statements than we could have without.

–
– Tom M.

17

Why bother? The whole point of ActiveRecord is to insulate the
programmer from having to write SQL in most (now almost all) cases.
Prepared Statements could be implemented as an optimization of how AR
connects with the database, but have you seen any apps that are are
not scaling because AR is speaking plain SQL?

Prepared Statements aren’t even necessarily faster.

        - dan

–
Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

18

As far as I’m aware, neither Google nor Amazon use J2EE for their
public-facing websites. At that level you roll your own solution.

19

Isak H. wrote:

On 7/21/06, Henning K. [email protected] wrote:

And also - who says J2EE is faster? I believe that’s as much hype as
anything.

Ruby, the language, is dog slow, while Java runs about as fast a s
possible.

OK - and the point is? I said you had to decide between raw performance
of the language itself, and productivity of your developers. Again -
what would you prefer? Buying more (commodity, cheap) hardware - or
spending the money on increased development time and complexity
management?

Also, Active Record is somewhat primitive, lacking support for
prepared statements, for instance. This means your app and database
are spending a fair amount of resources on parsing and planning the
same queries repeatedly.

True. Prepared statement support is lacking - but there is a reason. The
inherent dynamic nature of Active Record makes prepared statements a bit
of a no-go. However, there are ways to alleviate this. With Oracle, for
instance, you can set up the database to “semi-prepare” statements for
you that have the same general syntax (select firstname, lastname from
people where id = “23” automagically becomes select firstname, lastname
from people where id = :1).

Java is superior in other regards as well, for instance when it comes
to distributed transaction support and messaging.

Yes. But the question is - do you really need it, or can it be achieved
via simple scale-out with commodity hardware? If not - sure - go with
Java. Java has its place in the world, there is no doubt about that. So
does .NET, if you’re so inclined. DISTRIBUTED transaction processing
to me sounds like bad application design. It can just as easily be
achieved via database loading-tables and triggers/stored procedures.
Database transaction handling belongs in the database, not in the
application/web layer.

That said, I generally prefer rails for anything that doesn’t require
massive throughput or distributed transactions…
Then, after all, I believe we are on the same page (although I might
lean a bit more towards Rails even in performance-intensive cases).
Performance can be achieved in numerous ways. Load-balancing, caching
(rails internal, assisted via memcached, or simply via massive amounts
of RAM on the db/web servers).

Regards,
Henning K.

20

On Monday 24 July 2006 18:19, Mark H. wrote:

Ruby is plenty fast enough for 90% of the sites out there. Â Hardware
is cheap, programmer’s salaries are not. Â The vast majority of us are
not running Googles, Yahoos, Amazons, eBays, etc.

As far as I can tell, the comments so far have been focussed on
throughput. This is obviously important for public-facing web apps. For
inhouse applications, though, it is not much of a concern. There, it
counts for more to achieve short response times. I’d be interested what
others’ experiences are in this regard.

Michael

–
Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/