Forum: Ruby on Rails RoR for a Large Scale App?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
mojo.talantikite (Guest)
on 2007-06-05 00:48
(Received via mailing list)
I've seen discussion on this topic in the past, and was wondering what
people's feelings were in regards to the more recent releases?
Mainly, could it be possible to build a web application on the scale
of, say, Amazon, or deal with similar bandwidth and load requirements
as an iTunes would?  It may be unfair to expect that much, seeing as
these are some of the largest around, but would a setup of RoR scale
to handle this and, if not, what are the limitations that prevent it
from handling it?

Basically, I'm about to embark upon a large scale project and am
weighing my options, and the small amounts of RoR I've developed with
I've loved -- yet I just don't know how far it can go.  Thanks for the
input.
unknown (Guest)
on 2007-06-05 00:54
(Received via mailing list)
What kind of numbers are you talking about?
How many users, total, concurrent, etc...

Quoting "mojo.talantikite" <removed_email_address@domain.invalid>:
Tom M. (Guest)
on 2007-06-05 00:58
(Received via mailing list)
On Jun 4, 2007, at 1:53 PM, removed_email_address@domain.invalid wrote:

> What kind of numbers are you talking about?
> How many users, total, concurrent, etc...

How is that relevant? :-)

I'm joking here, sort of, but in the end it doesn't really matter!

Rails can scale, it just does so less efficiently than other frameworks.

The question is whether Rails' perceived advantages are more valuable
than eventual scale costs.

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Support, Scalability, Reliability
-- (866) 518-YARD (9273)
MichaelLatta (Guest)
on 2007-06-05 01:08
(Received via mailing list)
There was a good session (1/2 day) on scalability.  As pointed out by
the session presenter of the 26 TYPES of servers in their large scale
application only 2 are running ruby code.  There are load balancers,
databases, DNS, web servers, etc.  The level of infrastructure
required for a high volume site is significant.  The choice of
scripting language for the core business logic is a small part of the
puzzle.  With JRuby and JDBC database connections it is also possible
to get higher scalability if your issue is database connection
pooling.  I have seen nothing to suggest that Rails is unable to host
a major site.  But, remember also that major sites do not grow on
trees, nor do they spring full grown from the brow of Zeus.  They take
years to grow to that scale, and infrastructure will take many
iterations.  The biggest limitation to scalability is generally the
organizations ability to scale.  If you have a viable business model
the technical aspects are far easier to scale than the staffing.
Rails provides a good balance of production volume scalability, and
organizational demands.

Michael
Philip D. (Guest)
on 2007-06-05 01:10
I'm getting the feeling that it can be done.  The hard part is becoming
one of those guys who write code that writes code.  This is extra hard
because most people pick up Rails before Ruby.  If you know Ruby like
the back of your hand and have mastered the dynamics, then writing code
that writes code probably is easier.

Philip
www.myspace.com/MyITCompany    << just kidding!
Alexey V. (Guest)
on 2007-06-05 01:13
(Received via mailing list)
On 6/4/07, Tom M. <removed_email_address@domain.invalid> wrote:
> Rails can scale, it just does so less efficiently than other frameworks.
>
> The question is whether Rails' perceived advantages are more valuable
> than eventual scale costs.

Exactly. Rails can scale to epic proportions, but:

* You may end up with 2-3 times more hardware to execute that load
than an equivalent Java solution would need
* You may need to rewrite a few hotspots as native extensions
* You will have to be creative with caching

On the other hand,

* You may save 30-50% of overall development cost and time to market
* You may have similar savings on maintenance / ongoing development
* You may like your job a lot more that way

--
Alex
Alexey V. (Guest)
on 2007-06-05 01:20
(Received via mailing list)
On 6/4/07, Philip D. <removed_email_address@domain.invalid> wrote:
> The hard part is becoming
> one of those guys who write code that writes code.

?

Meta-programming is powerful, useful and dangerous.
But I don't see how it has anything to do with scalability.

--
Alex
Philip H. (Guest)
on 2007-06-05 01:21
(Received via mailing list)
> weighing my options, and the small amounts of RoR I've developed with
> I've loved -- yet I just don't know how far it can go.  Thanks for the
> input.

To follow up with what everyone else has said, you are going to have
database issues way way way before you're gonna have Rails issues.

And those database issues are gonna hit you regardless of what you pick
for your framework.

-philip
Philip D. (Guest)
on 2007-06-05 01:40
I guess what I am saying is that if you do not implement
meta-programming then your re-factoring workload will not scale up.  My
point is that in Rails, DRY only takes you so far -  and then you find
out you need to meta-program which is a different mindset.  Scalability
is a generic term most often used in the scope of performance.  I tend
to include more than one perspective when discussing scalability.

Just watch the screen casts for the streamlined plugin.  Obviously,
meta-programming was a crucial part of the design.  Try programming
streamlined with just DRY and no meta-programming!

Thanks,
Philip

Alexey V. wrote:
> On 6/4/07, Philip D. <removed_email_address@domain.invalid> wrote:
>> The hard part is becoming
>> one of those guys who write code that writes code.
>
> ?
>
> Meta-programming is powerful, useful and dangerous.
> But I don't see how it has anything to do with scalability.
>
> --
> Alex
Alexey V. (Guest)
on 2007-06-05 01:57
(Received via mailing list)
On 6/4/07, Philip H. <removed_email_address@domain.invalid> wrote:
> To follow up with what everyone else has said, you are going to have
> database issues way way way before you're gonna have Rails issues.

Sometimes, tuning up database access is not enough. Because Ruby
interpreter is as slow as it is, it happens with Rails apps more
often.
David M. (Guest)
on 2007-06-05 08:57
(Received via mailing list)
To Alexey's list, I'd add
* Is Ruby/Rails still going to be actively maintained/extended by the
time your app grows to the size of an Amazon or iTunes?

Don't get me wrong; I love using Rails, am waaay more productive with
it and can do things with it that I've never bothered to learn with
any other framework.  However, Rails has only been around for a few
years, has experienced stellar growth in mindshare over the past 2 to
the point where businesses now find it difficult to find good Rails
people, and there's only so much experience with using Rails on large
sites that actually exists in the world today.

At some point, some portion of Rails' mindshare is going to move onto
The Next Big Thing, and some chunk of Rails expertise in the market is
going to move with it.  On a purely technical basis, I can see no
reason why Rails won't continue to grow and take over large chunks of
the incumbent's (Java) domain; however, I'm old enough to remember
thinking the same thing about C++ ~15 years ago, before Java moved in
and took away a lot of C++'s turf.

And don't even get me started on Turbo Pascal!

Regards

Dave M.
Alexey V. (Guest)
on 2007-06-05 09:26
(Received via mailing list)
On 6/4/07, David M. <removed_email_address@domain.invalid> wrote:
> To Alexey's list, I'd add
> * Is Ruby/Rails still going to be actively maintained/extended by the
> time your app grows to the size of an Amazon or iTunes?

By now this doesn't look like a huge risk from where I sit.

--
Alex
Philip D. (Guest)
on 2007-06-05 11:20
"next big thing"


well it is right around the corner.  Consider MS and their .NET
extension which will eventually allow formal relational model style
integrated queries.  Consider also JSON and you can clearly see that
Ruby on Rails is going to be threatened very soon.  Here is one of the
bottom lines as far I as can tell:  Ruby R. you must iterate and
iterate and iterate.... but with the .NET CLR extension, MS .net users
will soon have a query language built right into the .net languages.  I
believe the query language extension will tap the object oriented side
and basically allow set-theoretric (relational model) queries on
objects- this is not available in ruby rails since you must always
ITERATE.
Alexey V. (Guest)
on 2007-06-05 12:15
(Received via mailing list)
> you can clearly see that Ruby on Rails is going to be threatened very soon
Surely, it's a fast-moving world.

On 6/5/07, Philip D. <removed_email_address@domain.invalid> wrote:
> well it is right around the corner.  Consider MS and their .NET
> extension which will eventually allow formal relational model style
> integrated queries.

If you are talking about LINQ, I played with that a little last year.
It saves one from writing quite a lot of boilerplate code, but is
hardly earth-shattering. In terms of productivity, mixins in C# 3.0
will have a bigger impact on actual .NET application development,
IMHO. And none of MS's new stuff attempts to cure productivity drains
of ASP.NET and Visual Studio.

If anything is going to displace Rails for web app development, it's
not coming from Microsoft, not any time soon.

Now, what the heck are we doing with this conversation on Rails-talk? :)

--
Alex
mpearce (Guest)
on 2007-06-05 12:42
(Received via mailing list)
You're talking about this:
http://joyeur.com/2007/05/18/slides-for-my-railsco...

If you take on a large project, consider yourself one of the people
who is in the position to contribute to the code in a unique way.
Think about how thankful we all are for those people.
This topic is locked and can not be replied to.