Scott Yang's Playground

How come this “highly scalable” framework can’t scale on the DB end? And you are partly correct, performance and scalability are different by in-extricably intertwined. True “shared nothing” offers some relief, but if you can’t scale your DB tier or can’t separate reads from writes while caching on the app->web pair, you’re in for a lot of pain.

The point Al3x is making is not that it can’t be done, but that the choice of framework makes it difficult to do it readily, and what is needed is time (not money or hardware). Rails makes it difficult because of retarded assumptions cloaked in an even sillier mantra of being “opinionated”.

Their basic response is, we’re opinionated, our opinion happens to be X at the moment, if you’re real world requirements are not X then too bad. It is sad to see a really great Rails adapter being attacked by sleazeball marketroids like DHH, because he dared to point to some issues publicly.

DHH’s response has actually been couterproductive. A VC looking at this will now think twice before committing their money to a startup using this framework. Mind you, VC’s are looking for this high-usage so the problems are very real, and very taxing on the bottom line.

Rails diminishes profit taking, it gives you a great site in 3 developer months, and how you to deal with the 3 sysadmin/dba years along with 10 times the servers.

What is the point of decreasing up-front cost when you’re backloading the total project with recurring costs of hardware/software maintenance? It is sad to see that most developers and rails fans cannot see this real concern.

Talk about “getting real” .

Actually, I was blaming the *platform*, hence the title of the post– service vs. platform. The language is part of the platform, but it’s much more than just a language.

It’s the same reason Reddit switched from Lisp to Python. Not because of the language per se, but because the platform around the language was so limiting. Look that one up if you’re curious, it’s interesting reading.

Also, I’m as mystified as you about Alex’s comments on the language speed. He’s the one who brought it up, and actually harped on it quite a bit with the Python comparison.

Scott,

I think your comment about one size fits all from a database scalability stand point is pretty much on the money, until you walk into the world of Oracle. As soon as you start clustering through RAC, it pretty much is one size fits all as you can keep flopping in more disks into a SAN and more nodes into the cluster. That being said, no start up could afford enterprise Oracle licensing, so I guess in this discussion its a mute point.

Regarding the language being slow, anyone thinking that Ruby/Python being the limiting factor in a database intensive site are kidding themselves. Lets assume an average 10ms response time for a single query, you can do an enormous amount of work in any programming language in 10ms – you’ll be waiting on disks/locks far more than the server side language to process something.

Would switching to .NET make a difference, sure it would. It would reduce the CPU time on their web servers, so they’d be able to serve more requests per second. Unfortunately, from what they’ve said – that isn’t their bottleneck at the moment, its database so although moving into .NET would yield better performance, right now it isn’t going to solve their current problems.

I don’t know enough about RoR, however I would have expected that it comes with a comprehensive set of caching utilities like Django does? I believe Django currently comes with file system caching, local memory caching, local/remote memory caching (memcache) – which as far as I understand, allows you to cache as high as the raw HTML output and right down to an individual object. Do you suppose Twitter currently have caching patterns in use?

Al.

Scott, I agree with your point in the comment below, I guess your sentence regard a shared nothing platform threw me off (causing me to go off on a contra-DHH rant – my apologies!)

I agree that a true shared nothing framework would help in a situation that twitter is in. Speed of Ruby isn’t as critical either, agreed again with your and Jeff’s point, when you are not in a straightjacket that is.

The point I was trying to raise was, RoR claims to be shared nothing, but for that to be true, the DB tier has to scale horizontally as well. The DB architecture would have to scale as well. I don’t think it is a trivial case, but for a system to claim “shared nothing” status, it ought to apply that to the DB tier as well. So, by default, Rails cannot claim to be “shared nothing” and yes, Ruby’s speed has very little to do with it, I was treating that point as a given.

The problem is that all that I/O has to be routed through the database, and partitioning your DB horizontally or vertically or Horiz/Vert + Read and Write pools is difficult with Rails even if you want to do it. By Default you start out with one DB, and since Rails happens to be an “opinionated” framework, whatever that means, it does not offer a natural path to this partitioning of Data on the DB end in a graceful manner.

I’m not sure how exactly Twitter is architected, but hopefully they are looking at a high performance messaging backend which speaks to various different kinds of clients, a Rails UI server being just one of them. I think the issue is that they are trying to handle all these messages using Rails and the framework is just not suited to that kind of soft-realtime requirements. Just because Twitter started out as a Web app, and happens to have a web interface doesn’t mean it is a web app, it is a messaging app with a web interface, but it also has to speak to IM, Twitterrific, and ad-hoc API calls. Maybe a Pure Ruby backend would offer a better performance profile, but to do it all through the layers that rails routes these packets through is just asking for trouble.

I would suggest that the backend architecture be broken down in two logical parts. One, lets call it Message Handler (MH) does nothing but message handling and routes them asynchronously to a DB store, and the other communicates MP (message Processor) with the various “internal” clients, one of whom happens to be a Rails frontend serving their website. The others maybe IM handlers, Mobile handlers etc. It might be better to write the MC and MH parts in Erlang perhaps while the web UI is handled by the Rails frontend which talks to the MC via a specialized “DB adapter”, ie; the MC exposes itself as a DB server. I have read somewhere that The Twitter team is using ejabberd in some capacity, but maybe it is only to talk to all the IM and Mobile clients all the while passing the info back to the Rails portion which commits new info to DB and reads back stored info.

I couldn’t think of a worse platform than Ruby on Rails, to write the messaging portions (MH + MC) in. While it is probably the one of the better ones to write the web front-end in.