# Multiple apps on the same server, all should be able to surv **URL:** \ **Category:** Deployment\ **Created:** [March 2, 2007, 9:50pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480 "2007-03-02T21:50:29Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 2, 2007, 9:50pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/1 "2007-03-02T21:50:29Z")
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. 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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 2, 2007, 9:56pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/2 "2007-03-02T21:56:30Z")
> - normally, the load is insignificant, but from time to time any of these > 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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 2, 2007, 9:59pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/3 "2007-03-02T21:59:30Z")
We’ve experimented a bit with a LiteSpeed/LSAPI combo for hosting as many Rails apps as possible w/o overcrowding. LiteSpeed seems to have a couple of features particularly favorable for this sort of setup: - It will start w/ one LSAPI process, but scale up and down dynamically as necessary, up to a specified limit - You can set resource limits at the web server level on your LSAPI processes So far, our experience has shown us that LiteSpeed/LSAPI works great for running a lot of small sites on a single server, and is dead- simple to set up (LiteSpeed comes with a web-based admin which allows you to do most of the legwork of setting up new sites). However, LiteSpeed did not work well for us for larger applications. For that, we still use good 'ol Apache/Mongrel. ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 2, 2007, 10:11pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/4 "2007-03-02T22:11:34Z")
> simple to set up (LiteSpeed comes with a web-based admin which allows > you to do most of the legwork of setting up new sites). However, > LiteSpeed did not work well for us for larger applications. For that, > we still use good 'ol Apache/Mongrel. Chris - Can you share what issues you had for larger apps? And was that with their 2.x or 3.x server? At work we’ve got a couple of the servers running litespeed and a couple apache/mongrel and so far haven’t noticed any issues… but maybe are apps are different… Thanks! ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 2, 2007, 10:18pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/5 "2007-03-02T22:18:36Z")
I don’t know all the intimate details of what was happening… but on one of our higher traffic applications, LiteSpeed seemed to be spawning an excess number of processes, leaving behind several dead processes. This was causing our application to run very slowly. We didn’t dig too much into it. Instead, we switched the app to Nginx (I mis-spoke earlier when I said Apache) and 10 mongrels, which seems to run great. LiteSpeed runs very well for our smaller sites (typically 1-3 processes each). I think we have this setup on 20-30 of these smaller sites and we haven’t had any issues. ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 2, 2007, 10:50pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/6 "2007-03-02T22:50:39Z")
On 3/2/07, Chris A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > However, LiteSpeed did not work well for us for larger applications. What distinguishes a large app from a small one? And what do the problems look like? Alex ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 3, 2007, 12:26am UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/7 "2007-03-03T00:26:51Z")
On Mar 2, 12:49 pm, “Alexey V.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > - normally, the load is insignificant, but from time to time any of these > these scenarios (if not, what’s the limitation, and can it be fixed?) > 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. Alex, sorry if I am being Caption Obvious here, but do you cache at all? If you can get away with caching complete pages as static HTML, you wouldn’t have to worry about Mongrel and Rails at all. If that’s not possible, have you considered Rails’ page fragment caching or a more custom caching solution? It feels like any web app with that much traffic in a short amount of time would be rendering the same data and making the same calculations repeatedly. Scott ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 3, 2007, 1:43pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/8 "2007-03-03T13:43:41Z")
> 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?) Not sure what is the bad reputation of Lighty + FastCGI, the only reference I know about problems with Lighty is about the proxy module. Zed doesn´t recommend it because of staled development that prevented some bugs of being fixed. Considering your scenario, it looks like FastCGI with a well tuned set of rules should be able to handle the both your normal low load, and the peak loads your apps receive from time to time. FastCGI whas designed to handle this kind setups. – Aníbal Rojas > **[RUBYCORNER.COM](https://www.rubycorner.com/)** > > RUBYCORNER.COM - Contact us for any business inquiries [http://www.hasmanydevelopers.com](http://www.hasmanydevelopers.com) ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 3, 2007, 1:58pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/9 "2007-03-03T13:58:43Z")
On Mar 2, 10:17 pm, Chris A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I don’t know all the intimate details of what was happening… but on > one of our higher traffic applications, LiteSpeed seemed to be > spawning an excess number of processes, leaving behind several dead > processes. This was causing our application to run very slowly. We > didn’t dig too much into it. Instead, we switched the app to Nginx (I > mis-spoke earlier when I said Apache) and 10 mongrels, which seems to > run great. We ran into this issue and it just turned out to be a configuration issue that was fixed with some fine tuning. The litespeed config for 2.2 can be somewhat confusing in the wording and throws many people off. They cleaned much of this up in 3.0. I came across this thread which helped: > **[Getting Lots of Ruby Processes](https://www.litespeedtech.com/support/forum/threads/getting-lots-of-ruby-processes.581/)** > > I am testing LS on a VPS running RH9. It is not beng accessed by more than 3 people. Probably none of them concurrently. > > When I restart the server I have 2 ruby instances. In the 6 or so hours since I restarted this morning, I now have 16 ruby... After a few config tweaks everything was kosher. ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 3, 2007, 11:12pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/10 "2007-03-03T23:12:54Z")
One issue with Litespeed is it’s closed source. A key piece of your IT infrastructure, completely dependent on a small company? This situation created some interesting problems in the past. Not to mention the licensing costs ($1400 per box). It’s not a show-stopper, but is there an open-source alternative that actually works? Re page caching: yes, absolutely, page caching rocks, but it’s not always possible, and even when it is possible, it is not always implemented. Re bad reputation of lighty + FastCGI combo: most open source software is written out of frustration (either with existing solutions, or with your day job, and usually both). As far as I know, both Mongrel and mod\_fcgid were written out of frustration with mod\_fastcgi. Best regards, Alex ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 3, 2007, 1:47pm UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/11 "2007-03-03T13:47:41Z")
I would also recommend litespeed. Though we’re only running one app, we were running into the same memory issue with Nginx + Mongrel\_cluster. Since we switched to litespeed we’ve had much more memory available plus better performance. To top it off its a BREEZE to setup and maintain. On Mar 2, 9:49 pm, “Alexey V.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [March 4, 2007, 1:34am UTC](https://www.ruby-forum.com/t/multiple-apps-on-the-same-server-all-should-be-able-to-surv/87480/12 "2007-03-04T01:34:05Z")
Alex, > Re bad reputation of lighty + FastCGI combo: most open source software is > written out of frustration (either with existing solutions, or with your day > job, and usually both). As far as I know, both Mongrel and mod\_fcgid were > written out of frustration with mod\_fastcgi. That’s a kind of pessimistic view of “scratch own itch” 😉 As far as I understand mod\_fcgid with Apache 2.x is the way to go because of the troubles with the mod\_fastcgi implementation of fastCGI for Apache 1.x. Mongrel is an alternative, and simpler approach, based in the use of a well know and workinf technology: reverse proxies. SimpleCGI (first Zed try) as a protocol is really simple compared to FastCGI, wich is really powerful but complex. But I am not sure where are the Lighty + fastCGI issues reported … What have been reporte are the problems with proxy. Best regards, – Aníbal Rojas > **[RUBYCORNER.COM](https://www.rubycorner.com/)** > > RUBYCORNER.COM - Contact us for any business inquiries > **[Home - Has Many Developers](https://hasmanydevelopers.com/)** > > We are the best choice for your building design and development