Whoops, my grammar on that middle part was horrendous. What I meant to say was:
Is work_to_develop(ROR site) + work_to_optimize(ROR site) work_to_develop(C++ site) + work_to_optimize(C++ site)?
I think we can safely say that work to develop is less for RoR, but is the work to optimize that much more for RoR? Also by “C++”, I mean “some fast framework, perhaps written in C++”, not absolutely C++ and not from scratch. All this is complicated stuff. YMMV.
Also, there’s no way I believe that Java is only 50% slower than C++. That’s gotta be a typo.
Java is fast, Swing is slooooooooooooooooooooow…
"this is why i don’t believe in ‘one does everything’ monster framework. "
You don’t believe in frameworks because in the case of one where the site became monstrously popular it started to stress the framework? Unfortunately for Twitter, their design is all about constantly updated data and a zillion writes with far fewer reads (I imagine), so you can’t save yourself with caching like usual. A little short-sighted about not being able to talk to multiple databases, but it a href="http://tomayko.com/weblog/2007/04/13/rails-multiple-connections"doesn’t seem to be accurate anyway./a
Twitter’s been a hit. All this means is they may have to spend some time rolling changes into Rails or re-imagining their data layer(s). Not the kind of thing you want to do in version 0.2, but there are worse problems to have.
“Comparing C++ into the equation is a little short sighted and those people who are defending C++, you really have no argument here as when was the last time someone created an entire web application in C++?”
Well, for example, I have. Web check-in for a major airline. And it’s one serious butt-kicker in performance compared to the alternatives. The company I work for does C#/ASP.NET (and a couple of JSPs) as well, and we get decent performance out of them, but they’re much tougher to maintain than the C++…Believe It, Or Not!
Here’s someone who has scaled Rails, enough to satisfy clients that collectively “process something like 60% of the US population’s health claims every year.”
http://tomayko.com/weblog/2007/04/13/rails-multiple-connections
Ryan writes:
When I consider what contributed to the unraveling of J2EE,
one thing that stands out is that it tried to do too much.
The promise was that of infinite scalability based on tooling,
which assumes that designing scalable systems is a general case problem.
I now firmly believe that this is flawed reasoning.
And the money quote:
Frameworks don’t solve scalability problems, design solves scalability problems.
I think a number of commenters here have made the right points:
The speed of Twitter is entirely about the database. I’m a little surprised the developers have even bothered to talk about Ruby’s performance.
The choice of underlying technology can’t be made entirely on considerations of what would be best for when you’re as popular as Myspace. You also have to consider the effort to get the service off the ground. Somewhere out there could be a dedicated team building a Twitter-clone on an enterprise-class foundation, but we haven’t heard of it, because they are still working toward 1.0. Start-ups are all about making intelligent compromises. Twitter has hit it big: hard to argue that they made a wrong decision someplace…
Python’s byte-compiled, Ruby is actually interpreted. In any case, the slow bit here seems to be the database, so blaming Ruby is a little odd (though blaming Rails may make sense).
I’d be a little dubious about that chart of programming language speeds given; saying that C# is compiled (but to bytecode) while Java is ‘byte code’ (thus also compiled) seems odd, and Python is sort-of compiled too.
Clearly, it should be written in Common Lisp. 
In my experience, the speed of Python depends a lot on how much time you are spending in C implementations of core functionality and how much in the interpreter. It’s a little frustrating sometimes - at best it ties patches of C together with a thin layer of dynamicness and approximates other VM’d languages in speed, at worst you’re trying to do number crunching in it which can end up crazy amounts slower.
I imagine the same applies to Ruby.
This post is below your usual standards Jeff. It’s been quite clearly stated that the issues the Twitter folks are facing are database related. I’m also stunned that anyone would see a data driven service that has to handle 11,000 requests a second and think that the bottleneck will be in the computation instead of I/O.
Side note: I have zero experience with rails and little with Python. I am a DBA so here is what I am seeing.
Without the mention of which database and the hardware that it is on, one can only speculate on what the biggest hurdle is. Databases handle inserts very well, about as fast as the underlying disks. This might be an issue with :
Doing updates/deletes along with inserts. Updates and deletes incur 2 or 3 times as much disk I/O. This would be a design flaw, eithe in their app or in rails (again, no expert here - just speculating).
Their hardware setup is incorrect for their size/# of hits. Solid state disks are VERY expensive, so lets assume that they do not use them. The next best set-up would be RAID 0+1 on many small drives. This spreads the disk I/O across many drives. This is also expensive because the drives require more disk controllers, more space in the rack, more drives will fail - so more hands-on replacement of said drives, etc… RAID 0+1 on large drives. This is probably what they are using. It provides decent I/O and cost ratio. This (or just RAID 1) is used by most business that had a dedicated admins (datawarehouses aside). Another setup could be RAID 5. This is not ideal for databases, expecially if they have a lot of writes (so data warehouses typically use RAID 5 for better read performance).
Too many indexes/triggers on the tables gettig written to. Each index at leasts doubles the disk I/O.
These were just a few of what could be amiss. Of course, 11,000 requests a second is quite a bit. This could very well be the database software itself not being able to handle that load.
I’m afraid I have to agree with Marcus and Dare, Jeff: this was not your best work. And I say that as someone who has a Coding Horror sticker on his Windows laptop.
The database ‘problems’ might be because of RoR
If you never write the SQL how do you know it’s optimal? Over time fragmentation of the table/indexes occurs (this is especially true when you update a lot and you get page splits). If you had stored procs it is so much easier to tune the DB. Even if the DB is the bottleneck this can still be because of the SQL generated by RoR. Are the indexes optimal for example? Too many and inserts/updates suffer. too little and retrieval suffers
Denis
I’m surprised at the number of people saying Twitter is only facing database problems. The quoted article was pretty clear about the problems with RoR:
“The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time.”
It’s Rails itself that doesn’t scale, not the database. A lot of other web platforms have features to deal with this sort of mess.
“Ask somebody trying to run an enterprise application on .NET right about now about how much downtime they have to schedule in to deal with the endless security patching.”
WTF? Did you pull this one out of your ass? Can you give me a example of this “endless security patching” or did you make that up?
“Ask somebody trying to run an enterprise application on .NET right about now about how much downtime they have to schedule in to deal with the endless security patching.”
You mean MySpace? Which ran on ColdFusion and couldn’t handle the load
OK, I’m sorry, but if any of my sites hit 40 millions requests per hour I’m certain I’m going to have performance problems. This is almost a non-issue. We have had similar problems on a much smaller site using hibernate. In addition on a miniscule site with 20 users we have monstrous performance problems using EJBs.
The common problem in all of these was that we where trying to do more than the database was capable of handling. True a properly tuned database might help with our problems, but, most often we didn’t tune anything until we had problems. In fact, we did that by design, why tune it before you need to?
In all cases there where fixes available.
In fact, we did that by design, why tune it before you need to?
I don’t agree with you.
Because it will be too late then, you start by writing proper code to begin with
If you write proper database code and have a proper data model then in all likelyhood you won’t have to tune that much
However if you write
SELECT * instead of listing the columns when you don’t need more than 2 column your IO will be greater
Or if you have a WHERE clause like this: WHERE LEFT(Col1,3) = ‘ABC’ instead of
WHERE col1 LIKE ‘ABC%’ you will get a fat-ass table/index scan instead of an index seek
This is not optimizing this is knowing how to write SQL
In theory you should not have to change your SQL that much if you have perormance problem. You couldhave federated database servers, partitioned tables, log, data, nonclustered indexes and data on separate drives. Reindexing/defragmenting indexes etc etc etc
Ugh, the clueless language fanboys are at it again. That’s what you get for posting performance metrics. 
Jeremiah is of course correct, C# is JIT-compiled byte-code just like Java, so it’s close to C++ but not quite as fast. If someone claims to have C++ code that’s actually slower than the equivalent C# code then that someone doesn’t know how to write and/or compile decent C++ code, end of story.
Also, standard Python is NOT compiled to machine code. The textual code is compiled to byte code, but that byte code is then interpreted rather than JIT-compiled. There are tools like Psyco that add true compilation but Psyco is still slower by at least an order of magnitude than Java or C#. Don’t know if someone has come up with a better independent Python compiler yet. IronPython for .NET is said to be pretty fast, though.
This is DHH’s “opinionated software” home to roost. Many have made the point on the RoR blog. The issue is that DHH, and RoR fanboy acolytes, insist that all logic goes in the code; the database is just dumb files (think: here’s the 60’s again), fronted by a SQL parser (and that’s all base MySql is). Some on RoR have tried to get the thinking going the other way, and Migrations might be a step that way.
I first this from Artima,and the real article says Twitter uses Postgres, which while nice, doesn’t do the necessary structural things you get with DB2, Oracle, and SQLServer. They’re not free, but sometimes you get what you pay for.
Nothing scales better than an industrial strenght RDBMS, if you know how to use one. Remember: their developers have been doing parallel processing programming for decades. Like it or not, they’ve learned more about how to do that than you have. Take advantage of it: put the data and smarts in the database, and use the application for the pixel dust. Then you can scale to the moon, Alice.