> Dear all, > > I am researching solutions for "how do you squeeze as many Rails apps as you > can on a cluster" problem. > > Environment constraints are as follows: > > * 4 commodity web servers (2 CPUs, 8 Gb of RAM each) > * shared file storage and database (big, fast, not a bottleneck) > * multiple Rails apps running on it > * normally, the load is insignificant, but from time to time any of these > apps can have a big, unpredictable spike in load, that takes (say) 8 > Mongrels to handle. > > The bottleneck, apparently, is RAM. At 100 Mb per Mongrel process, you can > only put 320 Mongrel processes on those boxes, and under specified > parameters you can only handle 40 apps on the hardware described above. PHP > can handle thousands of sites under the same set of constraints. > > We could use lighty + FastCGI combo, but it has a bad reputation. I wonder > if it's because of bugs in implementation, or it's just not designed for > these scenarios (if not, what's the limitation, and can it be fixed?) > > If anybody knows a ready-made solution to this problem, please let me know. > The last thing I want to do is reinvent the wheel.
Look into litespeed. I recently switched to it for my home server for the same reason (on a much much much smaller scale :). It can automatically spawn lsapi (rails) instances on demand (with a variety of cap levels such as process, memory, etc.) and then shut them down after they are idle for a certain amount of time. Their free version limits you to 150 connections at a time (active connections, not queued in the network connections) so it sounds like you'd need to pay for it, but still might be worth looking at. I think the free version also only utilizes one CPU... I got it because i have several apps (in addition to all the 'normal' unix server things) on a small box that hardly get any traffic. litespeed keeps rails "off" until I hit them, starts them up, then shuts them down 5 minutes after I'm done. -philip > > If anybody knows a load balancer smart enough to start and kill multiple > processes across the entire cluster, based on demand per application, please > let me know about that, too. > > Finally, I've been thinking about making Rails execution within Mongrel > concurrent by spawning multiple Rails processes as children of Mongrel, and > talking to them through local pipes (just like FastCGI does, but a > Ruby-specific solution). This may allow a single Mongrel to scale 3-4 times > better than now, and also to scale down if no requests are coming in the > last, say, 10 minutes. A "blank" Ruby process only takes 7Mb of RAM, perhaps > a "blank" Mongrel is not much more (haven't checked yet). Wonder if this > makes sense, or am I just crazy. > > I think, we can implement (and open-source) any solution that needs weeks > rather than years of effort. > > Thoughts? > > Best regards, > Alex Verkhovsky > ThoughtWorks > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
