rails has become a lot better in the years thanks to the core devs, contributors and the community for pushing it that way. it definitely depends on how you build your application.
there are couple of things i can recommend and i am following them in practice. - optimize your queries like hell. - design your database well and so you can avoid joins as much as possible. for example, you can have posts and comments. in order to display comment count of blog post in your blog home page, instead of doing the following query "select count(*) as count from comments where post_id = x" you can add a column in posts table called as "comment_count" and show them there. - use faster solutions wherever you can. - use solr or sphinx for full text searching. - make sure your views are perfectly fine and does not contain ruby code more than enough. remember, the rendering takes time, as well. - cache whatever you can. good luck. On Apr 6, 4:26 pm, Peter Bell <[email protected]> wrote: > On Apr 6, 2011, at 4:06 AM, Alexey Muranov wrote: > > > I think i understand David's point: "scalable" is true or false. > > I'm not sure that is Davids point at all. It sounds like he has experience > with building scalable applications and notices that some best practices for > scalability like UUID primary keys are not the default way in Rails. It seems > to me that he is more than sophisticated enough to realize that scalability > isn't a binary choice. > > > Could be nice if scalability was planned for from the beginning. > > I think there are some architectural defaults that could be changed which > would help, but scalability is so large, complex and specific to a given use > case I don't think there's any way to "just build scalability in". > > > I do not know anything about it, but i hope that the issue discussed > > here is only about Rails, i hope that Ruby can be used for scalable > > applications. > > Rails has some conventions which are not optimal for scaling certain types of > applications. All languages can be used for scalable applications - although > you need to look at the performance characteristics at runtime for a given > application. The main issue for scaling with Ruby is that it's an OO rather > than functional language which raises fundamental issues in managing mutable > state. You can work around that by writing Ruby in a more functional style > and using architectural patterns that don't depend on such shared state. > > I think a way more interesting question is whether Rails is productive than > whether it is scalable. I would much rather build something quickly in a > productive framework and then revisit parts of the app if scale became a > concern than spend way more to build a scalable app that nobody ends up > using. I use Rails for it's productivity and am enjoying it more with each > project I deliver. > > Best Wishes, > Peter > > > > > > > > > > > Alexey. > > > -- > > Posted viahttp://www.ruby-forum.com/. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Talk" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/rubyonrails-talk?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
