A real scaling discussion.

[Aaron Blohowiak]

In light of the recent levity, perhaps we should bring it back to brass tacks.  What are the main talking points when you confront the anti-rails FUD?

For me, it is:

• YAGNI, 
• easy to re-factor slow parts, 
• most of the time is spent in the database, 
• shared-nothing scales wide

The one part that is a real PITA to optimize is rendering times.  While not part of scaling per se, latency is a big factor in perceived application speed. Partials that render partials that render partials in loops can really add up!

There is this neat hack-job: http://github.com/acunote/template_inliner but I have not used it.

Any other tips/ideas?

-Aaron

[Courtenay]

ESI / typhoeus, if it's that big of a deal :)

Also, lots of really granular frag caching helps too.

> --
>
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails meets the business world" group.
> To post to this group, send email to rails-b...@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-busines...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-business?hl=en.
>

[Justin Dossey]

On Dec 7, 10:38 am, Aaron Blohowiak <aaron.blohow...@gmail.com> wrote:
> In light of the recent levity, perhaps we should bring it back to brass
> tacks.  What are the main talking points when you confront the anti-rails
> FUD?

Most of the time I hear people complain about rails speed is in the
early stages of a product. Since their new idea is going to so
successful that every person on earth will have an account and their
pets will have two, they want to be sure that their framework doesn't
become an obstacle to its success. In reality, most ideas don't even
make it to launch, much less hit the Interweb Lotto. I tell customers
to save on developer time (thus solving the problem of saving money)
now, and worry about problems they don't currently have once they
become probable. That way, their awesome idea will become profitable
faster and they can afford to deal with any scaling problems they
have, once they actually are on the horizon.

For the tl;dr crowd: fix the problems you have before you fix the
problems you think you might someday have.