On Apr 6, 2011, at 10:17 AM, mengu wrote: > 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.
I think all of those are really good points, but they relate to incremental scaling up, not scaling out. They will allow you to get more performance from a single server. For substantial scale, it's more a case of architecting so that you can throw multiple servers at the problem. I've never tried to build out a Rails app with ten front end servers speaking to a cluster of back end (SQL) db servers, but I'm guessing there would be problems with database contention and you'd start to have to take a lot more interest in failed saves - especially if you need to scale a write heavy application. That's where a fundamentally different architectural approaches based on designing from the get go for eventual consistency and asynchronous messaging are really important (assuming you don't need immediate consistency for most of your app). Personally I quite like the event sourcing model (http://martinfowler.com/eaaDev/EventSourcing.html) as it effectively gets rid of mutable state and makes any database values for entities a cache rather than an authoritative source. It's a different way of writing things, but it makes scaling out trivially simple. If I get some time I may have a play to see the best way of providing an easy implementation of this in the Ruby world. I see something here (https://github.com/cavalle/banksimplistic#readme) but haven't had a chance to play with it. That said, I just got brought in to do some architecture on a JRuby app that is going to genuinely need substantial write scaling from day one, so I may just get a chance to play with some of this if it makes sense to keep this in Rails vs. just using Rails as a thin layer and handling all the contention logic using a message bus or an eventually consistent, write scalable NoSQL data store like Cassandra with callbacks for contention handling. Best Wishes, Peter > > - 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. > -- 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.
