

Ruby Scales, and It’s Fast – If You Do It Right - jmonegro
http://www.engineyard.com/blog/2010/architecture-wins-varnish-and-more/

======
idlewords
I don't think anyone seriously argues that it's impossible to scale Ruby
websites, and make them run quickly with caching and various optimizations.

Rather, the trouble with Ruby (and Rails) is that you end up having to
implement these optimizations much faster than with a lighter-weight setup
(like PHP on top of a vanilla database, with no ORM).

Hence all the discussion about your "stack", middleware, load-balancing,
front-end servers, merbs, mongrels, passengers, and all the bewildering
variety of gems required for the care and feeding of a production app. Rails
developers write about armoring their app with all this extra stuff in a way
reminiscent of MMORPG players equipping a character for battle.

It's a legitimate trade-off, and many people seem comfortable making it. But
posts like this sidestep the issue. It's not that Ruby can't scale, is that
Ruby makes you fuss over scaling right away.

~~~
subwindow
Well, "right away" is kind of misleading. If you're the average company making
a Rails website, you'll get by with common-sense optimizations, database
indexes and the like that you'd have to do in PHP anyways. I've worked on
probably a dozen Rails apps and have only ever had to resort to horizontal
scaling and memcached once.

I think the key is that developing the app and scaling the app can be separate
tasks. If you do it right, for the lion's share of your app code is still
focused on the app, and all the caching and whatnot is handled elsewhere. In
PHP, if you had to use memcached it would be a massive change that would touch
every corner of your codebase. In Rails, you'd use a plugin and maybe a few
filters and you'd be good to go.

~~~
idlewords
I think that's a good description of the tradeoff. At some point, the filters,
plugins, middleware and so on that let you focus your energies on the app
begin to interact in non-trivial ways, and so the time you spent not having to
worry about them during development gets repaid worrying about them in
deployment.

------
kscaldef
... and if you only ever make one request, from one user, over and over and
over again.

    
    
        ab -n 10000 -c 1 -C '_redmine_session=9ec759408f1ae3c6f919e50baba5a3dc; path=/' http://127.0.0.1/
        Requests per second:    2839.37 [#/sec] (mean)
        Time per request:       0.352 [ms] (mean)
        Time per request:       0.352 [ms] (mean, across all concurrent requests)
    

This is an extremely unrealistic workload. It's the best possible scenario for
your caches. Yes, he says he was also browsing and editing the site at the
same time, but that's still nothing like modeling the real effects of cache
invalidation & overflow from many concurrently users.

~~~
newobj
Seriously... any _real_ load test, IMHO, needs to stem from a capture and
replay of live production traffic. Especially if it involves a cache
somewhere.

------
kvogt
I don't like this at all. "Scaling" usually refers to how easy it is to just
add more hardware to the problem.

But the thing that really irks me is the discussion of caching reverse proxies
and partial page caching. Those optimization techniques are language
independent. While I came to the same conclusions about usually needing these
with Ruby, I fully recognize that it's much slower at running complex
application logic and doing in-memory operations than other languages like
PHP, Java, and even Python.

Instead of arguing that Ruby isn't slow (because it is), I would have argued
that the time to build and debug a Ruby app is less than it would have been
using other languages. Extensive library support, an active user community,
many great tutorials / code snippets, no need to compile, and a pretty
flexible syntax make Ruby great for quick development. But let's not pretend
we can have our Ruby cake and eat it too.

~~~
sreque
Do you have anything to back that up? An implementor of a PHP static compiler
commented that the PHP runtime is horribly inefficient and is only able to
appear fast in practice because the majority of the standard library is
written in C. If you compare Ruby 1.9 to PHP on the Alioth tests at
[http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=php),
Ruby is very comparable in both memory and cPU usage and scores slightly
higher overall, beating out PHP. MacRuby and Rubinius are eventually going to
push Ruby performance even further, and right now JRuby already improves CPU
performance over the standard runtime.

Rails as a framework may do some inefficient things, and I've heard that the
next version of rails will address many of these inefficiencies, but as a
language runtime Ruby isn't any sloppier performance-wise than PHP and might
even already be better at this point.

~~~
igouy
> If you compare Ruby 1.9 to PHP...

1) "Ruby Scales, and It’s Fast" makes a point of talking about MRI not Yarv.

2) The fastest of those PHP programs relative to Ruby 1.9 (n-body and
mandelbrot) don't seem to make any use of the PHP standard library - which
undermines your "library is written in C" point.

3) If you look at the quad-core measurements you'll see PHP but you won't see
Ruby 1.9 or MRI because (unlike PHP) no one has contributed Ruby programs that
can make use of more than one processor.

[http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php&lang2=jruby)

------
drgath
If Ruby developers would stop trying to debunk the "Ruby and/or Rails doesn't
scale" myth, I think the rest of us would forget there was ever an issue.
Scaling a web app is language independent, and writing inefficient code is
also language independent.

------
cmelbye
I can't see why he used a single webrick process for testing this. It's widely
accepted that webrick should never be used in a production environment, so
this is a somewhat unrealistic test.

~~~
wyhaines
I used it because it's slow. Because the speed of Redmine running on webrick
isn't the point. The points are A) you can write some really fast stuff that
runs in Ruby, and B) if you do some prudent things like think about how to use
caching in front of your app, even a really slow app can effectively be very
fast when viewed from the outside.

