

Does Rails Scale? - uptown
https://bearmetal.eu/theden/does-rails-scale/

======
wbond
Whenever there are discussions about scaling and performance, I think it is
useful to at least reference the TechEmpower benchmarks as a data point.
[https://www.techempower.com/benchmarks/#section=data-r9&hw=p...](https://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=query)

In terms of scaling, I've observed that many engineering organizations drop
the idea of full-stack or monolithic anything for a couple of reasons. The
first is understanding all of the major constituent parts of their system, and
secondly to make it easier to replace any part that is identified as a
bottleneck.

~~~
hkarthik
I'll add that many engineering organizations also began to drop the idea of
full stack development as they grow and split up into independent, semi-
autonomous teams. When you have 300 engineers writing code into one monolithic
code base, a lot of the advantages of a monolith become major liabilities. You
can throw a lot of process and tooling at it, but eventually it slows you down
enough to the point where splitting things apart makes far more sense.

------
debacle
The ruby interpreter is really, really slow. I don't think anyone will argue
that you could do something Google or Facebook scale with rails.

That said, ruby is an incredibly easy language to program in. If you start
with ruby and an SOA, it doesn't matter where you start to hit scaling issues
- you can replace the code (that you wrote far faster than you would have in
Java) with something more performant.

~~~
vec
One of the main points of the article is that the only way to do Facebook-
scale sites is to have an architecture that scales out horizontally without
incurring any extra overhead, and that rails does so out of the box. So yes,
you could quite easily run something at Facebook scale with rails, it would
just require more physical servers than a more performant framework.

~~~
markuz
you can always solve any problem throwing money at it. I guess the main point
is running the same thing with 30% less servers, not more.

~~~
vec
You can't actually solve a lot of problems by throwing money at them. Ensuring
that scaling your core application to arbitrary traffic sizes is in the class
of money-solvable problems isn't trivial and should guide your architectural
decisions from day 1.

Yes, you'll probably end up doing significant rewrites if you do actually win
the lottery and get big, but it's nice to know that you're not going to top
out at some arbitrary size and have to start turning customers away while you
do those rewrites.

------
eweise
There are other frameworks that are as productive and have better performance
so why cripple yourself right from the beginning.

~~~
Jgrubb
What would those frameworks be?

~~~
eweise
Here's one [https://www.playframework.com/](https://www.playframework.com/)

Here's another [https://grails.org/](https://grails.org/)

~~~
vorg
Groovy (the dynamically typed version which is the only one anyone uses) runs
as slowly as Ruby, if not slower, so wouldn't Grails too? Scala's statically
compiled so perhaps Play runs quicker than both. I don't know about the
various frameworks productivity though.

~~~
eweise
Grails is mostly java wrapped by a light layer of groovy. Based on
[http://www.techempower.com/benchmarks/#section=data-r9](http://www.techempower.com/benchmarks/#section=data-r9)
its a lot faster than rails.

~~~
vorg
When Gradle 2.0 came out earlier this year, I looked at its source and there
was virtually no Groovy code left in there, only the minimal needed to
interface with the DSL. Not much of an advert for using Groovy for anything
other than scripting when its two big showcase projects don't use it for
building their own code bases.

------
matthewmacleod
Aside from a few specific edge cases, any limits on scaling you hit when using
_any_ technology—Rails included—will be down to application architecture
rather than the performance of the framework or language.

In particular, I don't think comparisons to Facebook or Twitter are
particularly helpful. Twitter is basically global telecom-scale; Rails is
never going to be the right tool for that, but the flipped of that is it was
possible to get to that point using it.

Basically, use whatever framework or language that suits your other
requirements. Build a sensible, modular system using standard software
engineering principles. Don't sweat over the scalability of your framework
until you hit scale, and you'll have a great problem to deal with.

------
carsongross
Proper system architecture can make any not-completely-insane web layer scale.
Concatenating strings is typically a round-off error compared with touching
the network, as the author mentions.

That said, I'll disagree just a bit with the author: trying to get the rough
system architecture correct early on by squinting at your app domain and
estimating where the load is most likely to hit hardest, then putting in
effort to make sure those areas are particularly scaleable and resilient, is a
reasonable approach, even if it smacks of premature optimization.

~~~
jarkko
Original author here.

I don't think we really disagree there. I might not have made it clear enough,
but I mentioned that there are obvious things that need more consideration,
like Kissmetric's or Skylight's data aggregation and massaging.

That said, for many (most?) that culprit is not easy to identify in the early
stages and many apps are still basically glorified CRUD apps where that is a
non-issue to begin with.

For example, a few years back we ran a much publicized vote for an
unidentified social network with more than a billion users. It ran on a run-
off-the-mill Monorails[1] app and MySQL, without any hitches. If anything, we
vastly overestimated the number of app servers needed (a couple dozen IIRC).

Of course it was a fairly simple use case, just an example that high load by
itself doesn't mean much.

[1] A term commonly used for a web app that is a single Rails application, as
opposed to a more SOA-style app split in smaller pieces.

------
lmm
I think the concise counter is that, as PG says, startups should do things
that don't scale. Scaling is a nice problem to have, too many people
prematurely optimize.

~~~
jarkko
Counter to what? One of the main points of the article was exactly what you
wrote in your second sentence.

------
jkmcf
Rails performance scales linearly with money. You save money on the dev side,
but you'll need more servers sooner than more performant languages/frameworks.

------
moe
Can a slow car move lots of stuff?

Sure, you just use more of them.

------
markuz
try compiling a super simple sass file multiple times. The time it takes
varies so much. Ruby's performance is not predictable.

The point here is why the same algorithm would take 0.3 sec to run and the
next time it would take 1 sec. After seen that I never coded Ruby again.

------
fn
Amazed that we are still having this discussion several years later.

~~~
jarkko
You can't imagine how many times that crossed my mind before and while writing
the article. FWIW, much of it is not Rails-specific by any means, and we'll
always have a new crop of developers asking these questions.

