
Why Ruby/Rails speed doesn't matter? - luccastera
http://www.blik.it/2007/10/01/why-rubyrails-speed-doesnt-matter/
======
jawngee
I wrote this as a response, but it's awaiting moderation:

I think this article is pretty irresponsible. Your making some weak excuses
for Ruby's poor performance that, frankly, speaks more about your laziness as
a developer than it does about Ruby.

One just needs to point at Friendster for an example of what happens when your
application is too slow at the wrong time. When Friendster started hitting it
big, a long time ago, they couldn't deal with the load and they lost a lot of
marketshare because of it. On top of it, they undertook a huge effort to
rewrite it in something faster, but it was too little too late.

Furthermore, when application availability is crucial to the success of your
application, you had better be thinking about performance well before it
becomes a problem. Throwing more "metal" at the problem isn't a solution, and
you even point it out in your article, "if you can't afford a cluster of
Opterons just yet, you're just using some average VPS slice and you're on a
tight budget for the first month". Well, if you're on a tight budget how are
you going to afford that extra metal to throw at it?

"Good enough" doesn't cut it, and if I'm an investor in your company and the
first spike in traffic nearly kills the application and we lose market because
of it, well your laziness is going to be the first thing I evaluate.

Note that I'm not promoting any language in response, because it's not really
a language issue. Anything you bring to bear on the public, performance should
be a primary concern. As a CTO in a company, it's my chief concern, to be
honest.

An ounce of prevention ...

------
davidw
I'm a big Rails fan, and have pretty much been using it exclusively lately.
However, I've been around the block enough times to know someone trying to
cover for a language's weak points when I see it.

I think the honest analysis is: "When considering all the tradeoffs in
creating something, the slow speed is not a deal breaker for the kind of app
I'm writing. On the plus side, I get something that's very fast to write apps
with, a big, helpful, smart community, and the prospect of a faster language
in the future".

------
tx
5 requests/second is "good life average"? While he certainly deserves a credit
for trying to shoot conservatively, but such low numbers will only scare more
people away.

Our slowest requests (with multiple SQL queries and nontrivial rhtml
rendering) get served @25-30req/sec, while "regular", i.e. not heavy requests
are served @60-120req/sec and we're certainly not "Rails sharks" having less
than a year of real life experience and our server is a $850 Opteron box.

~~~
mkull
Just to clarify a bit, he is being conservative, and it's 5 req/sec per
mongrel (4 mongrels), which would come out to 20 req/sec for the vps setup.

~~~
nickb
And you can easily add another slice to this setup...

Author definitely has a point. If you're picking a new language for your
project, I wouldn't worry about Rails' performance at all.

------
jamiequint
It would be awesome if the hits on your site were spread out completely evenly
over the course of a month, yet when is that ever the case. Say you were to
get dugg, I have to imagine that at a concurrency rate of only 20 reqs/sec
your site would probably go down.

------
fauigerzigerk
He does have a point. But what still bothers me is that if even a single
important part of my app does something computationally expensive (which is
typically the case in my apps), I have to interface with C. Writing C code is
fine, but the interfacing stuff is no pleasure at all. So I would be glad if
Ruby could run, say, 50 times as fast as it does ;-)

~~~
Zak
Might I suggest Common Lisp? SBCL is 50 times as fast as Ruby (standard
disclaimer about generic language speed comparisons not being very accurate or
meaningful).

~~~
fauigerzigerk
Is there a reasonably mature web framework for SBCL?

~~~
Zak
There are a number of tools available for making web applications using Common
Lisp. Most or all work well on SBCL. I don't think any are as mature as Rails.
Most Lispers don't take the all-in-one approach of Rails - they're more likely
to use a collection of libraries than a framework. Some tools to look at are
Hunchentoot, CL-WHO, HTML-template, Weblocks, Uncommonweb, CLSQL and Kpax.

------
cstejerean
well, as long as the choice is between ruby and python I don't really care.
Each has its strengths and weaknesses but they are both pleasant language to
write things in. Developer time is worth more than CPU time but I think that
Python and Ruby would have to be at about the same level in terms of developer
productivity (I use both Python and Ruby but I use Python a lot more than Ruby
so maybe there is some Ruby magic that I'm not aware of that would make it
MUCH more productive).

