The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

What's all the fuss about Ruby On Rails?


I keep reading about RoR in diverse Internet forums for the last few months and I cannot stop wondering. Don't get me wrong: Ruby is a nice language (even a bit nicer than Python, a quantum leap compared to PERL). But, in my eyes it's yet another quite small (and feature-reduced as it is still new) framework, that will get bigger and more complex over time. And eventually get less "cool". Also, at the moment RoR lacks many API's (WebServices – the one I'm mostly interested in).

Why not use JAVA (JSP/J2EE/whatever-Java-based) or .net (ASP.NET): All these web application frameworks are MVC-based (RoR is, too) but they are mature, have feature-rich API's and modern languages. Not to forget the IDE's. I'm still wondering why RoR?
Saturday, July 09, 2005
First, I'm not sure what you're referring to about RoR lacking many APIs. It's written in Ruby: you get the full power of Ruby's standard library. Which, I might add, does in fact include web services. What features do you feel are missing? I readily admit it doesn't have quite the wealth of code available to use that Java does, but I've found that nearly any problem I want to tackle can be done easily with Ruby.

I suggest you try it out, it won't take long. I threw together a prototype web site for a potential client in about a day. Don't get caught up in the buzzwords; being MVC isn't uncommon, what is uncommon is the speed and ease that you can write an interactive site using RoR and ActiveRecord. That's why I suggest you try it: on paper it looks somewhat comparable, but when you use it, you see how productive you can be. And more importantly, you can get this speed without sacrificing the quality of the end product..
Anon to protect the guilty Send private email
Saturday, July 09, 2005

The big advantage over most of the Java frameworks I've used is that there aren't any XML OR mapping files to set up.  You add fields to a table in the DB, and if you're using the automagic scaffolding, it shows up in your UI.  Yay dynamic languages.

I'm not sure if I would release a high-traffic production application on it, (OK, I am sure -- and I wouldn't :-)) but it's great for circle-of-friends webapps and prototypes.

Knowing ruby well and knowing rails not at all, I had a fairly simple site up in about four hours, including user authorisation, media uploading and resizing, and a largeish data import (100M or so).
Art Send private email
Saturday, July 09, 2005
Yeah, you're right. There indeed is a XML WebServices API in RoR (called Action Web Service). After researching a bit, I see that it supports SOAP/WSDL and XML-RPC but both are not (yet) feature complete, whereas most things are implemented. I probably understood it wrongly the first time I read it somewhere on the Internet. Other important Ruby API's seem to be there too (at least on the paper ;)).

I was skeptical too about developing "high-traffic production application" on RoR but then I realized that the Basecamp is developed using it (RoR actually arose from Basecamp). I think a few individual performance tests would show how Ruby performs under a heavy load.

That said, I'll take a look at RoR. I must admit, I like it more than PHP but (as I grew up and live in the world of Java and Microsoft COM/VB/VC++/ASP and now .net) I see RoR as a child with good potential but still a child.

PS – Other opinions are still welcome.
Sunday, July 10, 2005
I'll say up front that I don't know anything about the performance and scaling characteristics of Ruby on Rails. But I have to wonder if Basecamp is really a good demonstration of a "high traffic production application." How many REAL users does it have? How many hits per second does it take over a long period of time? How big are the databases behind it?

From what I've seen, the majority of the people who play with Basecamp are doing so because it has a lot of buzz and they want to see a "real" Ruby on Rails app, not because they're true users who will use the app for its intended purpose day after day. Even though it is not be intended as such, it feels more like a proof of concept demo than a real product. So I'm not convinced that Basecamp is really seeing the usage patterns that I'd associate with a true high-traffic production application.

What would happen if you tried to build something like Yahoo! or Gmail or with Ruby on Rails? Would it really scale to that size? Few of us develop applications on that level. But I think that many of us want to design our software so that it *could* scale to that size if necessary (without having to rewrite it from scratch). Ruby on Rails may well be capable of doing that, but I haven't seen anyone demonstrate it yet...

Sunday, July 10, 2005
I just read this interview ( with the founder of 37signals, the company behind RoR.  They  do very little consulting work now (it used to be their main revenue source), and are deriving most of their income from BaseCamp & BackPack.  Of course, it doesn't say how much revenue they are making or how many users they have, but they seem to be doing well, so I think that their products are a little more than demos for RoR.

Sunday, July 10, 2005
The big issue I have with rails scalability is admittedly based on some prejudices I have about large scale webapps.  Rails doesn't really have a model of a stateful server, primarily because there is no threading, connection pooling, etc.  You have one lighthttpd/apache/whatever thread, and it has one rails instance, which has one db connection, etc.

I can't shove a lot of stuff into a middle-tier process and expect it to be there for subsequent requests from the same user, because he might be going to a different Rails instance.  Almost all of the state needs to be stored in the session (which is persisted to a shared filesystem) or the database, which means the application scales linearly with the database.

That's the part I'm not comfortable with for large installations -- by which I mean at least hundreds of thousands of users per day.  I don't have a feel for how many users Basecamp has, but I suspect it's not at this scale.  However, I do think you could probably support a few thousand active users for under $50k in hardware and software license costs (the db requiring the expensive hardware), depending on the complexity of your application.
Art Send private email
Sunday, July 10, 2005
According to:

There are several commerical applications that boast well over 6,000 registered users on their ruby applications. Of course that doesn't mean all six thousand users are actively logged in and using the application, but it seems ruby at least scales to medium sized levels.
Aspiring High School Developer
Monday, July 11, 2005

How many websites run at this scale?  Not many.

Would you build all cars and freeways to the same specification as Formula 1 racing?

I think I should start posting on all those enterprise server forums with comments like 'I'm concerned that this won't scale down very well.  Could a team of 3 provide 24/7 support while extending functionality?  We only have a couple of thousand users and at the rate the market will accept a bigger team would not be economical.  The thing is, we 3 really want to do this rather than ending up as corporate drones wasting our existance in a cubicle."
Ged Byrne Send private email
Monday, July 11, 2005
scalability is an important issue when choosing a development environment. If it is not scalable, you made the wrong decision and you will be rewriting your app into something that is scalable once you start getting customers. And this is just the wrong time to have to start worrying about rewriting your app. It is always better/cheaper/faster to do it right the first time rather than plan for a rewrite in a new environment once you start getting busy.
Monday, July 11, 2005

"How many websites run at this scale?  Not many."

Every one I've been paid to build or work on in the past five years, which is why I disclaimed my opinion as prejudicial or biased.

The scaling down question is more interesting, and it's where Rails shines.  One person with a reasonable professional skill set could easily design, build, deploy, and maintain a high-value application.  You can't really say that for ATG, Broadvision, etc., because you'll need at a minimum an RDBMS expert (especially if you're using Oracle), a Java expert, a Unix expert, a networking expert, etc., to deal with all the tuning and local environmental constraints.
Art Send private email
Monday, July 11, 2005
There is a big difference between making a prototype web app that 6-50 simultaneous users can use without problem and a web app that 100-1000+ simultaneous users can use without problem.

All development environments can easily handle the first. It sounds like RoR is in that camp.

6000 registered users could mean 1-10 simultaneous users or 6000 simultaneous users. From a previous post in this thread it sounds like most of those registered users are one time viewers, which implies there is not much simultaneous traffic.

So can RoR handle traffic? Any real data out there on it? Or is it just another a highly hyped prototyping tool that will need to be rewritten in a more robust environment once your app becomes successful? If that's the case, you are better off sticking with php from the start, right?
evaluating RoR for real applications
Monday, July 11, 2005 (RoR app)

40,018 people are doing 135,115 things…

Looks like not-light concurrent CRUD may be happening there...

Note I didn't say heavy, but "not-light" :)
Tuesday, July 12, 2005
Otherwise, here's more about RoR scalability :)

Back to that issuing of Rails scalability...
Posted by schubert 70 days ago
I was reminded of the topic when I was catching up on my misc@openbsd mailing list and I caught this end of a thread:

    From: Theo de Raadt
    Subject: Re: Hackathon 2005
    Date: April 30, 2005 7:02:03 PM PDT

    > While I'm not a developer, I do believe it
    > scales reasonably well writing
    > their own implementations.

    Scaling isn't really our concern; I barely know what the word means. There is one group of people who we do know scales. Whiners. They scale really well

Zing! :-)
Tuesday, July 12, 2005

Something that you support now is most important.

What if you can only afford a small team and you deploy an over-complicated stack for the sake of scalability.

You have a couple of hundred users all paying a monthly subscription, but something goes wrong deep in the bowls of your enterprise stack.

Your team doesn't include the specialist in something or other to quickly solve the problem, so you have a couple of days downtime.

Subscriptions are cancelled, revenue drops, the company goes bust.  Scaling was never an issue.

Isn't it better to start with something that is within your means to support, something that allows you to keep the design clean and clear?
Ged Byrne Send private email
Tuesday, July 12, 2005
Besides, arguments about scalability are a non-issue.

Ruby On Rails pushes most of the hard work onto the most proven of all scalable workhorses: the relational database.

Proponents of the Java stack may crow about the scalability of their frameworks, but on the frontline it is choking in complexity.

Long term, complexity is as important as performance. 

True, Rails is yet to prove itself in terms of scalability, but Java still has some way to go.

Rails can do the simplicity, but can it manage the performance?

Java can do the performance, but can it manage the simplicity?

Remember that Java was once the slow, unproven contender itself.  It won out against C++ because of reduced complexity, not because of increased performance.
Ged Byrne Send private email
Tuesday, July 12, 2005
I've said it before, but it bears repeating: There's nothing interesting about how Ruby on Rails scales. We've gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty.

Take state out of the application servers and push it to database/memcached/shared network drive (that's the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy).

In a setup like that, you can add almost any number of web and app servers without changing a thing.

Scaling the database is the "hard part", but still a solved problem. Once you get beyond what can be easily managed by a descent master-slave setup (and that'll probably take millions and millions of pageviews per day), you start doing partitioning.

Users 1-100K on cluster A, 100K-200K on cluster B, and so on. But again, this is nothing new. LiveJournal scales like that. I hear eBay too. And probably everyone else that has to deal with huge numbers.

So the scaling part is solved. What's left is judging whether the economics of it are sensible to you. And that's really a performance issue, not a scalability one.

If your app server costs $500 per month (like our dual xeons does) and can drive 30 requests/second on Rails and 60 requests/second on Java/PHP/.NET/whatever (these are totally arbitrary numbers pulled out of my...), then you're faced with the cost of $500 for 2.6 million requests/day on the Rails setup and $250 for the same on the other one.

Now. How much is productivity worth to you? Let's just take a $60K/year programmer. That's $5K/month. If you need to handle 5 million requests/day, your programmer needs to be 10% more productive on Rails to make it even. If he's 15% more productive, you're up $250. And this is not even considering the joy and happiness programmers derive from working with more productive tools (nor that people have claimed to be many times more productive).

Of course, the silly math above hinges on the assumption that the <i>whatever</i> stack is twice as fast as Rails. That's a very big if. And totally dependent on the application, the people, and so on. Some have found Rails to be as fast or faster than comparable "best-of-breed J2EE stacks" -- see

The point is that the cost per request is plummeting, but the cost of programming is not. Thus, we have to find ways to trade efficiency in the runtime for efficiency in the "thought time" in order to make the development of applications cheaper. I believed we've long since entered an age where simplicity of development and maintenance is where the real value lies.
David Heinemeier Hansson Send private email
Tuesday, July 12, 2005
Not only do I agree with DHH that web app scalability is a non-issue with Rails, but I also think that you've been addressing the wrong scalability question.

The important question is do programmers scale? Can ten programmers do ten times the work of one programmer? Most of us are aware that there is clear evidence that programmers *do not* scale.

From this perspective, Rails scales spectacularly better than the alternatives by boosting programmer productivity.
Curt Hibbs Send private email
Tuesday, July 12, 2005
"If your app server costs $500 per month (like our dual xeons does) and can drive 30 requests/second on Rails and 60 requests/second on Java/PHP/.NET/whatever (these are totally arbitrary numbers pulled out of my...), then you're faced with the cost of $500 for 2.6 million requests/day on the Rails setup and $250 for the same on the other one."

I'm going to assume (and may be wrong) that you have the largest traffic going to a Rails site.  I'm not really concerned about registered users, because those of us who lived through the .com boom know that's a meaningless figure.  What's interesting is the volume you're seeing on basecamp/backpack/tada/etc.

Are these representative figures?  Are you really only able to support 15 tps/cpu on a dual Xeon?  Is that peak or sustained?  At that rate, yes, you can scale out that tier massively before you sweat the DB.

From what I've seen, though, these are very silo'd applications -- as a user, I deal with my data, and I don't really see anyone else's data.  That works out pretty well in terms of the partitioning model you outline.  You can build out cheap dual-proc boxes with lots of RAID and not worry too much about hitting a shoulder of a curve because, for all intents and purposes, there is one user for each very specialised webapp.

My area of specialisation is online commerce, which brings with it a lot of baggage that some other webapps don't have to deal with.  The biggest issue is that there are more external connections.  We have credit risk systems, credit card processors, search engines, tax systems, home delivery scheduling systems, cross channel pricing engines, product masters, third party content aggregators, order fulfillment systems, etc.  Some of these require synchronous interaction and some don't.

For this type of application, where you're building a system and not just a thin layer of business logic on top of a database, scaling isn't just "adding more servers".  You hit a rush of customers and discover what I would call "standing waves" -- an overloaded messaging system, a broken distributed cache, high latency on a remote connection to a third party system, whatever.

This is the part where Ruby makes me a little nervous.  I remember very well the huge relief that the first JIT JVMs and native threads were, even though they could be very buggy.  They solved so many problems that we had to think through with a team of $100k developers. (West coast US, there wasn't much cheaper with a decent skillset.)  If we could have solved the problem with hardware, we would have, but there was only so much that a single CPU could do.  Today, if I could only support 30 tps on a box, it would cost so much more to build out a web store that only the smallest sites and the largest sites could justify.
Anon for this
Tuesday, July 12, 2005

The barrier to entry for any programming environments are
typically acquisition costs, the learning curve and backend
(often unknown) costs of the decision to focus on the environment. Programnmer's don't make these decisions lightly and many push back on anything that's over-hyped.

Rails is being hyped significantly... but a close investigation reveals some ideas that will be widely implemented because they create an awesome demo of productivity. In a few months the Rails approach to
scaffolding will be re-engineered in every major framework
becuase it's just elegant simplicity... (Trails implements something like it for J2EE... it still has all the XML
description requirements but most of the complexity has been
coded into the framework).

So, look deeply into the rails phenomena and weigh your skepticism against the realities of the tool. It's a killer app and we'll be measuring a lot of framework against it for it's productivity boost for those first critical weeks of coding in a new framework.

For those who aren't up to speed with the tool just spend
a few minutes and watch the Rails demo video... It makes the ease-of-use case rather effectively and the designed of the technology is giving the demo. He's selling his baby pretty hard but it's it's going to start a rush of investigation into Rails and Ruby becuase Frameworks are still just too friggin' hard to master. Rails will probably be a challenge to master but at least you'll have a site up and functional while you rack your brain against the internals. For amyone that believes in getting something working and then making small improvements,
Rails is compelling.

The video can be seen at:

Dave McDorman Send private email
Tuesday, July 12, 2005

I understand your perspectives and considerations. I would respectfully submit, however, that this is defintely an edge case in the overall web universe. I would guess that this level of coplexity represents 10% of all web apps (20% if you want to be generous).

Rails does not target this, but rather is intended to address that 60% sweet spot where most of us developer's live.
Curt Hibbs Send private email
Tuesday, July 12, 2005
Being involved with development for the past 20 years, including web development since the mid 90's there is one thing that I learned.

It's not the development environment so much as the developer.

No matter what environment you develop in, learn it.  Learn how to optimize it well enough so that you don't even have to think twice about it.  I'd even recommend learning details about every componant that your programs deals with, from the database to the users' browsers.  The more you know, the better.

Granted some development environments are slower than others, but a really good developer on a slow environment will always out perform a team of bad developers in a fast environment.

From my own personal experience, I'd have to say that RoR's is probably the significantly faster to prototype applications in.  From what I have read, few people would disagree.  As for how well it scales?  That all depends on the developers involved and how much time they take to understand where their bottle necks lie.

Just keep learning, it never fails you.  :-)
Tuesday, July 12, 2005
There are quite a few posts in this thread that seem to say scaling isnt as important as short learning curve or short ease of programming. What's up with all this super hyping? We are all programmers here. Take that argument to the beginner forums. We dont need to be handheld about how to program. We need to know what the facts are.

If RoR doesnt scale well, say so, we can atleast know that we are using a rapid prototyping tool that we can plan to migrate from when necessary.
Tuesday, July 12, 2005

This is the type of simplication we're arguing against.

There is no reason why Rails should not scale as well as Java or PHP.  The point is that it is still new, and it hasn't been used at that scale.

If Rails has never been used at that scale, then how can we have the facts that Rails does or does not scale?

Tbe point is that if you are basing your descisions purely on performance and scaling issues you really are missing the point.

The biggest problem facing development right now is not speed, it is complexity.

Rails is working on the problem of complexity, not performance.
Ged Byrne Send private email
Tuesday, July 12, 2005
Reducing complexity is a worthy goal. But it is not the only goal and it is not the most important goal for everyone. As mentioned, reduced complexity is great for rapid prototyping and reducing the learning curve.

There is a trade off for every decision and if that tradeoff is reducing complexity at the expense of performance, as an earlier poster mentioned, then it would be good to know that information up front rather than finding out when your server is crashing under load.
Tuesday, July 12, 2005
All speculation and claims aside, the only thing that will truly put the scalability question to risk is either an honest, independent study or a proven heavy real-world application with real usage/load numbers (basecamp is not what I would call a heavy test, and there's some question of conflict of interests as DHH is the author). 

Until either of these happen, all the discussion is just a bunch of hot air.  Don't get me wrong, I like RoR so far and want to see it succeed, but all this arguing is really useless without proof.
Tuesday, July 12, 2005

"Tbe point is that if you are basing your descisions purely on performance and scaling issues you really are missing the point."

This is so disingenous as to be a straw man.  Performance and scaling issues are critical concerns with definite requirements.  If the effort required is massive to make Rails scale past the simple stages of "cache more", "optimise sql", or "bulk up the hardware", then that's tremendously valuable input into the conversation.

As jbwiv says, to date, no large, complex, high-demand Rails application exists.  This is the point you are intentionally missing.  You can theorise that no constraints exist to prevent it from scaling linearly with hardware, but everyone who has deployed a large software package knows this is almost never true.

My initial statement stands, I love it for small apps, but I wouldn't take the risk of deploying a large application on it yet.
Art Send private email
Tuesday, July 12, 2005
According to the Agile Web Development with Rails book (which I have the PDF version of, print version is shipping soon) here are some real world traffic figures for RoR installs:

Basecamp - 400,000 dynamic requests a day without caching. "It’s currently handled by two web/application servers that each run 15 FastCGI processes and 50-100 Apache 1.3.x processes on dual 2.4GHz Xeons with 2GB of RAM. These  machines usually sit between 0.5 and 1.5 in load." The DB server is shared with other 37S projects including BackPack and Tadalist

43things - 200,000 dynamic requests per day. Same three server set up but with 3GHz CPUS. "Load on the servers rarely exceeds 0.3 and CPU idle time is usually in excess of 80%."

And one you probably haven't heard of, - 300 requests/second though the system was tested with 3,000. The cluster has ten servers. The application uses PostgreSQL for the database, lighttpd on the web  server, and around 10 FastCGIs per application server sitting behind a virtual server with IP tunneling"
Jon Gales Send private email
Tuesday, July 12, 2005 grew to 500,000 requests/day just recently. I believe they're still on the same hardware setup.
David Heinemeier Hansson Send private email
Tuesday, July 12, 2005

Only a fool would deploy Rails on a large app: it hasn't even reached version 1 yet!

My point is that the issues of scalability have been solved before for than more than one framework and platform.  I'm not saying it is easy, of course it isn't.  The point is that the problems that need overcoming to achieve this scalability are become a known quantity.  As Rails grows and gets progressively larger it will encounter these problems, and will be able to draw on those experiences in search of a solution.

The problems of complexity, however, are yet to be successfully overcome.  Since this is a greater unknown, it makes sense to make them the key focus.

Rails isn't the only project showing promise here.  The Spring Framework and Hibernate are also making great improvements.

It isn't enough to sit back and say 'we have solved the problems of performance, we have nothing new to learn.'  Complexity is a serious problem that has to be solved.
Ged Byrne Send private email
Tuesday, July 12, 2005
only a fool would use RoR for anything big? Wow, this from an advocate too.

I dont think anyone here is questioning or even asking whether RoR has a good solution for complexity. That seems to be a diversionary tactic to avoid the questions people ARE asking.
Tuesday, July 12, 2005

Do you find yourself constantly bumping into all the stuff that is neither black nor white?  All those hues in between causing you trouble?

Rails is a new, disruptive technology.  It is yet to reach version 1.  I advocate Ruby on Rails, not stupidity.
Ged Byrne Send private email
Wednesday, July 13, 2005
Several people here have asked straightforward questions about scalability and you ranted about scalability being stupid and avoiding complexity is the only thing to be concerned with. That kind of implies you are the one with color vision issues.

Me, I'm just looking into ruby and rails to see if they are worth using over php or python. I am not concerned with rapid prototyping nor with avoiding complexity.
Wednesday, July 13, 2005
I'm not going to pretend I am a guru in the art of "scaling", nor do I think I would ever want to be. But I do know that as a college student, Rails has given me a great platform to learn and grow as a developer. All the meanwhile I am learning a language that could be running larger sites in the very near future. Rails has allowed me to build CMS systems in less than an hour, provide better turnaround time to clients, and it also makes me look into new ideas and approaches constantly.

Even better than that, the community has been totally awesome in helping out, contributing, and developing both the language and it's supporters.

I don't know how Rails would do in a large application environment. My initial thought is it would be fine, with the right developers. Same goes for a project in PHP, ASP, whatever. You get the right people, you get the right results, perioed.

What I do know is that Rails, in terms of simplifing my work, and making programming fun and exciting again, totally scales.
Dominic Damian Send private email
Wednesday, July 13, 2005
The answer to the straightforward question was straightforward enough.

It is impossible to say how well Rails will scale until it has scaled.  Only time will tell.

How well did Java 0.13 scale?  The question is irrelevant, nobody would have dream of building a large application with that fledgling technology.  It was good for little animations on web pages.

How well does Rails 0.13 scale.  The question is irrelevant, nody would dream of building a large applicatoin with this feldling technology.  It is good for small to medium scale apps and prototyping.

How well will Rails 1.5 scale?  We'll see.

Is J2EE 1.5 hopelessly over complicated.  Yes.

Will Rails 1.5 be hopelessly over complicated.  We'll see.
Ged Byrne Send private email
Wednesday, July 13, 2005
Question: where did I say scalability was stupid?

I'll accept that I've ranted a bit, but I feel like Lou talking to Andy.

How does it scale for a million users.

It hasn't been deployed at that scale yet, so we can't tell.  It's doing well at 5,000 though.

Yeh, I know.

And its only been out a year.  It will probably be used in much bigger application by this time next year.  Maybe 50, 000.

Yeh, I know.

So in a few years time we'll know.  OK?

Yeh, I know.


So how it will scale for a million users.  Why won't you answer my question?
Ged Byrne Send private email
Wednesday, July 13, 2005
I don’t think I’ve read the word "scale" so often in my life. From the thread it would seem that people tend to think that scaling is the gold standard for a programming language. If it can "scale" (though few actually go into what they mean by scaling) then it is legit. Bull shit. I say if smart people can use it to do great things, then it is legit. Here is a quote I like:

"Would you build all cars and freeways to the same specification as Formula 1 racing?"

Obviously not. This goes right back to premature optimization, which is a MUCH bigger danger than having it not be scalable right out of the box.

Here is a quote I loath:

"If Rails has never been used at that scale, then how can we have the facts that Rails does or does not scale?"

And another one I loath:

"I like RoR so far and want to see it succeed, but all this arguing is really useless without proof"

Does this mean that before Yahoo started using PHP, nobody knew if PHP could scale? No, that is ridiculous. Smart people can make good tools scale. To highlight this nugget of truth further, think about this for a while:

PHP doesn’t scale. Perl doesn’t scale. Java doesn't scale. Ruby on Rails doesn’t scale. You know why? Because the vast majority of programmers don’t know how to scale any of these languages. This is the funny and sad truth of the situation: programmers clawing over each-other on whether a language or framework scales when almost none of these people will end up scaling their apps.

Non-smart people are a much bigger hazard to scaling web applications than any language or framework I can think of. Scaling a web app takes smart people with experience and good tools. If you don’t know whether or not Ruby on Rails is a good tool, give it a try yourself. Most smart people I know love Rails. More importantly, a lot of great things are coming out of the Rails community, which seals my stamp of approval.
Lucas Carlson Send private email
Wednesday, July 13, 2005

I like what your saying, but I think your missing one important factor: TIME.

The solution to scaling, or any important problem, requires smart people and TIME.

"Mistake number 1. The Get Big Fast syndrome. This fallacy of the Internet bubble has already been thoroughly discredited elsewhere, so I won't flog it too much. But an important observation is that the bubble companies that were trying to create software (as opposed to pet food shops) just didn't have enough time for their software to get good."
Ged Byrne Send private email
Wednesday, July 13, 2005
whatever. I'll figure it out for myself, since the hostility from the rails advocates in this thread seems to prevent any useful sharing of information.
Wednesday, July 13, 2005
Figure what out yourself?  You haven't asked any questions, just made assertions.
Ged Byrne Send private email
Wednesday, July 13, 2005
It sounds like rails is the new front page or cold fusion. It is easy for beginners to do lots of cool things, but then try to do something real and you have to move to a different platform or depopulate half your code because most of it is too slow to use under heavy use.

Why dual xeons for the one app that is using it with any traffic?
ruby maybe rails no
Wednesday, July 13, 2005
cornerbean, you say:

"scalability is an important issue when choosing a development environment. If it is not scalable, you made the wrong decision and you will be rewriting your app into something that is scalable once you start getting customers"

I disagree. I think scalability is a way of thinking and approaching problems, not a feature or a plug-in of a development environment. This is why it is moot to ask if any good tool can scale. Yes, Rails can scale. No it is not easy. It is not easy to scale in any development environment. It is tricky and time-consuming and takes testing and hard work. You would almost never want to start out by building a site that can handle 100k users a day, you scale as needed. If you write non-modular code on top of Rails, it will be very difficult to scale your site up with Rails. If you write modular code, it will scale easier. Asking "Does XYZ language/framework scale?" is like asking "Can someone from XYZ run a marathon?" Well yes, if they are prepared.

If you are rather trying to ask whether the Rails framework was well-conceived with good code and flexibility, upon which you can scale it to your needs: Yes, please take a look for yourself.
Lucas Carlson Send private email
Wednesday, July 13, 2005
Scalability is never a moot point and has nothing to do with effort. If the tools are meant for prototyping only, then no amount of effort will get you beyond that. If the tools crash on 50 simultaneous requests, no matter how much hardware you throw at it, you wont get very far.

Some languages and some platforms were designed with performance in mind and some were designed with hand holding in mind at the expense of performance. Whether RoR is the former or the latter can be determined by what tradeoffs they made designing it and by how well it holds up under load. You dont need to wait until a site becomes as big as google to prove that it scales, just run a simple test with a 100 simultaneous requests and 1000. Saying it is moot or saying it is unknowable is ridiculous and just show your bias.

Obviously a lot of folks here are sensitive about the word scalability for some bizarre reason. So change it to performance, instead. What is the performance of Ror compared with others under similar loads?

For all the hype about friendly, helpful community, you folks get awfully defensive over simple questions.
Wednesday, July 13, 2005
> If the tools are meant for prototyping only, then no amount of effort will get you beyond that.

Rails is not meant for prototyping only.  A cursory visit to could tell you that. :]

> If the tools crash on 50 simultaneous requests, no matter how much hardware you throw at it, you wont get very far.

43things and basecamp are pretty strong evidence that that is not the case with rails.

Since those two rather ridiculous edge cases don't apply to rails, we might as well focus on the real issues as Lucas outlined them. :-)

> Some languages and some platforms were designed with performance in mind and some were designed with hand holding in mind at the expense of performance.

I'm not sure those are mutually exclusive goals.  From my point of view, RoR looks like it was designed to be fast and fun for development, and I guess that means that performance wasn't the top priority.  But arguably, unless you're writing your web apps in assembly language, performance isn't your top priority.

With enough time and money, any (yes, any) solution can be made to "scale".  The real question is this: how much does it cost?

Of course that's a very subjective question with far too many variables to answer definitively, but I think DHH outlined several good reasons it would be logical to think that RoR "scales" economically.
Tyler Kiley
Wednesday, July 13, 2005
"Scalability is never a moot point"

So you are telling us that scalability is a very important thing for each and ever one of the 36 million websites out there? Ma and pa's ecommerce-to-go needs to make sure that it can server 50+ cousins at a time?

"and [scalability has] nothing to do with effort"

So to scale a website all you need is to use the right framework or the right language? Please tell me what framework scales effortlessly? I want to know. J2EE? Is it that the Java experts at Friendster didn't write enough books to understand how to scale effortlessly?

"If the tools are meant for prototyping only..."

So Basecamp and Odeo are prototypes... huh? What are you talking about? What web development framework is meant for prototyping only? Some people use frameworks for prototyping, but I don't know of any that were built for prototyping.

"Some languages and some platforms were designed with performance in mind [and those] can be determined by what tradeoffs they made designing it and by how well it holds up under load"

C is one of the fastest higher level languages there is. You are telling us that since C is fast, any website I build with C will scale well and hold up under load? I don't think so.

"Obviously a lot of folks here are sensitive about the word scalability for some bizarre reason"

I am openly sensitive to the word scalability because so many people hold it as the gold standard for any web framework, which is absolutely silly. Things that are much more important to me than scalability include maintainability, extensibility and flexibility. That is because those are very hard to retrofit onto an existing framework. Scalability is something completely independent of language choice and any half-decent framework as well.

"What is the performance of Ror compared with others under similar loads?"

What can you possibly mean by this? This is such a subjective question that no-one can answer it as phrased. If I write a "hello world" app in Rails, I bet it would load faster than Google, but more people can access Google than my "hello world". So what? What do you mean? A question that make some semblance of sense might be: "What are Rails' strengths and weaknesses compared to Java/PHP/.Net?" Or at least specifying how would you suggest measuring the performance of Ror compared to others.

"For all the hype about friendly, helpful community, you folks get awfully defensive over simple questions."

We are a friendly, helpful community for those interested in learning in a productive and interested way. If you ever have questions about what I have been doing with Rails to allow more users to concurrently access my sites, feel free to contact me. I'd be happy to discuss it. However I will not stand for people making silly statements like:

"If Rails has never been used at that scale, then how can we have the facts that Rails does or does not scale?"

And I won't stand for it on principal, not just because the word Rails is in there. Again, scalability is a silly and terribly overused metric for gauging a framework.
Lucas Carlson Send private email
Wednesday, July 13, 2005
You are attributing a statement from Ged to me. I never claimed anything about RoR. All I've been doing is asking for simple information on scalability. How is that in any way claiming that RoR is not scalable?

Simple question. You have experience with it under load, how about filling us in. How's it look.

Or are you content to follow all the rest and bash me just for asking, because according to this crowd asking about scalability is moot, stupid, and totally unknowable?

Anyways, I will test it out for myself under load and report back the results, since no one else is willing to share anything more than preaching hot air.
Thursday, July 14, 2005
According to both Lucas and Tyler everything can scale and it doesnt matter what tools you use as long as you write great modular code. So if I use access and front page, it will scale just as well as RoR, with just as much effort?

It sounds like that is what you are claiming. Correct me if I misunderstood your claim. My understanding of access is that it will die after a specific small number of total records. So that is a specific example where a rapid prototyping tool will NEVER scale beyond a certain maximum, no matter what you do. Likewise other frameworks have similar maximum issues, although clearly not that early.

The point is that choosing the correct tools for the job DOES make a difference in whether you can handle a load.

Claiming that it makes no difference and that you can ignore the tool choice because scalability is a moot point    or implying that scalability only means 100k simultaneous requests is just obscuring a real issue.

And I wasnt the one that mentioned 100k simultaneous requests, which is an edge case. Handling 100 to 1000 simultaneous request is not an edge case, but a simple question that most app developers would be interested in not stumbling over.
Thursday, July 14, 2005
cornerbean, allow me to quote myself:

> With enough time and money, any (yes, any) solution can be made to "scale".  The real question is this: how much does it cost?

Yes, I said ANY solution can be made to "scale".  (I'm using that term very loosely here.  In some cases, it may mean switching frameworks or languages, which is a cost of making the solution "scale".)

I went on to say that DHH's post earlier in this discussion outlined several good reasons it would be logical to think that RoR "scales" economically (without switching languages :p).  I won't rehash his points -- you can read them again yourself :)

The real, sensible question beneath the "SCALABILITY! SCALABILITY! SCALABILITY!" monkey dance is this: What is it going to cost to make site x support y visitors per second/minute/hour?  When you look at it from that point of view, there is good evidence to show that Rails is competitive, if not superior.
Tyler Kiley
Thursday, July 14, 2005
What a whopper. A solution doesnt scale if you have to change to a DIFFERENT solution. What a dumb thing to say.

So any car can be made to go 200mph, just change the car?

The point that I made and will repeat again is that choosing a tool without looking at its limitations is a mistake.

I have a theory why everyone here is singing the praises of RoR without answering with facts. It is just manufactured buzz. Forum spam.
Thursday, July 14, 2005
cornerbean, you're not thinking very pragmatically.

Whether or not a language/framework "scales" is irrelevant.  It's an artificial term, and it just doesn't matter.  What matters is the total cost of making your site support high(er) numbers of visitors.  And like I said, there is ample evidence that indicates RoR is competitive when measured like that.

When you say "solution", you mean language, framework, whatever.  When I say "solution", I mean a black box that gets a job done.  In that sense, any solution is scaleable, given enough time and money; the only variable is cost.
Tyler Kiley
Thursday, July 14, 2005
cornerbean, you have no idea what you are talking about.

"A solution doesnt scale if you have to change to a DIFFERENT solution."

Friendster had to change from J2EE to PHP. Does that definitively mean that J2EE doesn't "scale"? If so, does that mean that no websites should use J2EE?
Lucas Carlson Send private email
Thursday, July 14, 2005
Strawman arguments are just stupid diversions. We are programmers here and we are talking about Ruby on Rails. So whether Ruby or Rails scales is what we are talking about, not whether we can make our "solution" scale by changing to j2ee or to php.

The whole point of my discussion was to get facts about RoR under load. Not whether I can rewrite it into something else to make it scale. That is just a stupid argument and has nothing to do with what I was saying or what the thread is about.

What ample evidence? One claim about monthly stats on one site is ample evidence? The only ample here is fake hype and groundless opinions.
Thursday, July 14, 2005
muggins, cornerbean, etc: I've had an unconstructive attitude in this thread.  I'm sorry.  In these kinds of discussions, it's sometimes easy to just let your ego run wild and argue for the sake of arguing rather than to inform and become informed.  Let me take one more stab at the topic, and then I'll shut up. :-)

"scaling" can be split into two factors: 1) how much hardware you can throw at the problem, 2) how well the framework/language utilizes the hardware.

When it comes to adding hardware, rails scales like any other LAMP setup -- you can add application servers and web servers fairly easily.  The only real bottleneck (and even then only for enormous sites) is the database server, but that's a general LAMP issue, not a ruby/rails issue.  (Correct me if I'm wrong, but I believe the same limitations apply to php, perl, and python-based setups).

Rails may not be able to outperform java on similar hardware (on the other hand, it may.  The jury's still out.) but there is enough evidence out there to safely conclude that Rails' performance doesn't suck.  It's not ridiculously slow, and in some tests, it's on par with (or superior to) java.

In most cases, if hardware efficiency is fairly similar for several solutions (e.g. neither one is 2x as fast as the other), performance questions become secondary to development cost questions, since developers are generally more expensive than hardware.  If you need to use a beefier server to handle RoR, but it allows your developers to be slightly more productive, then I'd say that's a good trade off.

I guess the point I'm trying to make is this: we don't know that Rails can always outperform Java.  It probably doesn't.  But we know that its performance is somewhere in the same ballpark, and we have several examples of sites that use it on a moderately large scale with success.  For 99% of web development, that should be plenty of evidence.  Right?

Don't agree?  Fine.  What would it take to convince you that RoR can scale?  Why do you believe that any other language/framework can scale?
Tyler Kiley
Thursday, July 14, 2005
Wow, I've never seen so many strawmen defenses by so many intelligent people, in response to such a clearcut question! Lucas Carlson & co, why on earth could possibly be the reason for avoiding the question in this ridiculous matter?

If nobody has done load testing, fine. If you've done it, post the figures. I'm a RoR fan, but threads like this really puts me off the whole thing. What's this about RoR being more fun to code in, and switching from J2EE to PHP, or whatever, has to do with the performance of RoR under a heavy load? It's inane to even bring those things up.

That RoR is fun to program in, easy to prototype things in, etc. are all valuable points in favor of RoR. But the thing that so many people in this thread seemingly can't get through their heads is that this is not what cornerbean and others are asking about.

Bleh. I guess I'll just have to do the damn tests myself.
Friday, July 22, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz