Comments on: Ruby on Rails doesn’t Scale Well http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/ Utterly random, incoherent and disjointed rants and ramblings... Thu, 04 Dec 2008 19:19:50 +0000 http://wordpress.org/?v=2.0.5 by: Luke http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4259 Sun, 29 Apr 2007 03:17:35 +0000 http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4259 Wow! That was fast. Rails community really has it together. Thanks for sharing this! Wow! That was fast. Rails community really has it together. Thanks for sharing this!

]]> by: are.you.for.real http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4255 Sat, 28 Apr 2007 02:11:47 +0000 http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4255 <a href="http://www.loudthinking.com/arc/000610.html" rel="nofollow">I heart the Rails community.</a> Not only did Nic cure the database concurrency problems exposed in Rails by Twitter - he did it without being asked, he shared it with everyone (as a Rails plugin), and he did it in 75 lines of Ruby. Word. I heart the Rails community. Not only did Nic cure the database concurrency problems exposed in Rails by Twitter - he did it without being asked, he shared it with everyone (as a Rails plugin), and he did it in 75 lines of Ruby.

Word.

]]> by: Luke http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4254 Fri, 27 Apr 2007 19:36:40 +0000 http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4254 Database cluster sounds about right. Although if you have a single master node ruining the actual database server, you still get in trouble. What you would ideally want is to have several nodes listening for connections. But then you run into concurrency hell... Database cluster sounds about right. Although if you have a single master node ruining the actual database server, you still get in trouble. What you would ideally want is to have several nodes listening for connections.

But then you run into concurrency hell…

]]> by: meanguy http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4253 Fri, 27 Apr 2007 18:29:09 +0000 http://www.terminally-incoherent.com/blog/2007/04/27/ruby-on-rails-doesnt-scale-well/#comment-4253 i'm not a fan of rails -- but a database cluster is the correct solution here. the way to have rails talk to multiple database is to have multiple rails apps. with gems, the code sharing works cleanly. not sure how you'd "split" things otherwise at the model level. you can partition and play caching tricks, but that's just delaying the inevitable. due to concurrency issues only the database knows what needs to be updated and when. alex's quote referencing "read-only slave databases" and "caching" indicates that he hasn't really thought about the problem and is just another guy wrestling to make a half-complete system, complete. Cal from Flickr wrote an O'Reilly book that outlines some of the problems, even if the solutions are a little "on the sly" by enterprise standards. still, it's tough to argue with the results. though note that he talks at length about the amount of extra code they write that checks and double checks integrity of cache. and they've had some pretty bad caching bugs -- porn pics showing up, etc. a lot of this style of systems design is "okay for dopey web site" but not so good for financial or information systems design. whether or not this stuff works long term and ever scales up to "real" reliability remains to be seen. i’m not a fan of rails — but a database cluster is the correct solution here. the way to have rails talk to multiple database is to have multiple rails apps. with gems, the code sharing works cleanly.

not sure how you’d “split” things otherwise at the model level. you can partition and play caching tricks, but that’s just delaying the inevitable.

due to concurrency issues only the database knows what needs to be updated and when. alex’s quote referencing “read-only slave databases” and “caching” indicates that he hasn’t really thought about the problem and is just another guy wrestling to make a half-complete system, complete.

Cal from Flickr wrote an O’Reilly book that outlines some of the problems, even if the solutions are a little “on the sly” by enterprise standards. still, it’s tough to argue with the results. though note that he talks at length about the amount of extra code they write that checks and double checks integrity of cache. and they’ve had some pretty bad caching bugs — porn pics showing up, etc.

a lot of this style of systems design is “okay for dopey web site” but not so good for financial or information systems design. whether or not this stuff works long term and ever scales up to “real” reliability remains to be seen.

]]>