Does Rails Scale? | Hacker News Reader

Does Rails Scale?

bearmetal.eu

25 pointsuptown23 comments

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...

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.

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.

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.

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.

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.

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.

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

What would those frameworks be?

Here's one https://www.playframework.com/

Here's another https://grails.org/

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.

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

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.

You're going to need to be a bit more specific. What frameworks? How are they more productive?

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.

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.

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.

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.

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

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.

Can a slow car move lots of stuff?

Sure, you just use more of them.

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.

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

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.

Reply on news.ycombinator.com