But, right now, they *are* mutually exclusive: There's no way to use
Rails (and therefore gain it's benefits) without incurring this cost.
Tomas Jogin - What you need is LiteSpeed as suggested by Peter
originally. It spawns and manages application processes. If a
process is idle for X seconds, the process dies (you set X obviously).
You can even choose to not spawn rails processes on a server restart
in which case they would be spawned when the application get hit for
the first time. If you get very little traffic, you will probably see
very few processes running at any given time, even if your hosting 30
rails apps.
Joe: I'll have to look into LiteSpeed, but based on what I've read,
neither LiteSpeed is capable of having apps share Ruby processes
between themselves (which doesn't surprise me at all).
Some responses in this thread suggest that is the case:
>
> Joe: I'll have to look into LiteSpeed, but based on what I've read,
> neither LiteSpeed is capable of having apps share Ruby processes
> between themselves (which doesn't surprise me at all).
You I cant think of a good reason why you would want/need that (not
that there isn't one maybe). But I don't think the problem your
seeking to solve now is answered by sharing ruby processes.
Tomas, there is no *point* in sharing Ruby processes, when they are
spawned and killed according to need.
Exactly. Tomas, think in terms of total memory. Traditionally if you
have 30 apps, 1 process each at 20 mb ram, your using 600 mb of ram on
your server. Now say you figured out that on average only 1 of your
apps is "in use". If you were running litespeed that would mean on
average you would see 20 mb ram dedicated to rails apps.
You should still make sure your server *can* run everything at the
same time... otherwise you would be dependent on under-use which just
isn't good design in any server environment.
I suppose I might have jumped to conclusions regarding the nature of
the problem. The facts are that the server is running perhaps 30 Ruby
processes, and the server is equipped with 1.5 GB of RAM. I'm not able
to check more details right now, but I'll definitely have to make a
proper check later.
Well, if processes were spawned every time they are needed and then killed again after use, each time, you would have something very inefficient. But that's not the way it works. Your example is about as extreme as is possible.
Apache as a webserver manages do spawn threads pretty efficiently and can sustain high hitrates. If processes are left idle for a long time, they are killed, otherwise they are left to live to serve future requests. If all processes are busy and another request comes in, another process may be spawned, depending on configuration, to handle that request, and that process is subject to the same life- span restriction as the others.
That's very common knowledge. And yes, there is a overhead involved in firing up another process. You don't want to do it too often. But that's elementary resource management.
LiteSpeed does exactly the same thing but with Rails processes. However it also uses a FCGI implementation of its own to drastically reduce the startup overhead. The result is that you can let it handle the resulting resource allocation dynamically - without being overly bothered by process startup.
As for silver bullets, I've never seen one within the field of computer science, so that's not what we're talking about here.
No, and you don't want to. That is why processes were invented in the
first place. They provide separation.
Unix has a good set of tools to manage and monitor processes - which
would have to be duplicated inside any application server.
Why bother complicating matters with another layer of software that may
go wrong?. Memory is cheap and swap space is very cheap. Unix is a
superb multi-user operating system - providing wonderful memory
separation, process management and reasonable security controls. Why do
you want to use it like it was an early version of MS-DOS?
For ease of management though, I would suggest using Mongrel rather
than FCGI. It's just a lot easier when everything is talking HTTP.