Forum: Ruby on Rails Many apps == Many processes?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-28 12:37
(Received via mailing list)
Hi

I'm running several smallish apps each with small audiences and few
users, all on the same server. We're currently deploying on
Apache+FastCGI with few problems, except the fact that each app starts
a new dedicated Ruby process. The combined performance demand on the
server shouldn't be very high, but since the amount of apps is in the
thirties and since each and every one uses its own Ruby process, this
results in quite a bit of overhead.

My question is if this can be avoided. Is it possible to run many apps
that reuse the same Ruby processes and thus result in less pressure on
the server? What are my options?

Best regards,
Tomas Jogin, Sweden
5a8ab1ea865141adaa35ab9408435003?d=identicon&s=25 Jake Varghese (jake3030)
on 2006-12-28 19:02
Tomas Jogin wrote:
> Hi
>
> I'm running several smallish apps each with small audiences and few
> users, all on the same server. We're currently deploying on
> Apache+FastCGI with few problems, except the fact that each app starts
> a new dedicated Ruby process. The combined performance demand on the
> server shouldn't be very high, but since the amount of apps is in the
> thirties and since each and every one uses its own Ruby process, this
> results in quite a bit of overhead.
>
> My question is if this can be avoided. Is it possible to run many apps
> that reuse the same Ruby processes and thus result in less pressure on
> the server? What are my options?
>
> Best regards,
> Tomas Jogin, Sweden

this part is pretty hard.  I just ran into the same situation and i
still havent found an answer.

I was able to lessen the load.

In lighttpd you can set the number of FCGI processes per app.  I set
this to 1 for each app and was able to push the server (Athlon XP 2600,
1.5GB RAM) to about 90 sites with decent traffic. i think you can do
this with Apache also.

The problem is that each app needs its own FCGI process.

With the current Capistrano type deployment, you have one app with many
users.  This type of installation is much easier, because all of your
users go to one app, but in your case, you would need to separate them
and that's when stuff gets a little crazy.

Sorry,


--jake
Efe398b3b5436b0a8d4430090e8f86ea?d=identicon&s=25 seth b. (subimage)
on 2006-12-28 23:50
(Received via mailing list)
Right now I don't think there is. You have to run at least 1 process per
Rails app. This is true with FCGI and Mongrel. CGI runs and completes
its
process after Rails does its business (I believe)

The only hope for situations like this _might_ be the jRuby project.

http://headius.blogspot.com/2006/04/beginning-of-j...

On 12/28/06, Tomas Jogin <tomasj@gmail.com> wrote:
> results in quite a bit of overhead.
>
> My question is if this can be avoided. Is it possible to run many apps
> that reuse the same Ruby processes and thus result in less pressure on
> the server? What are my options?
>
> Best regards,
> Tomas Jogin, Sweden
>
> >
>


--
--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
74e21b54f21ba89e663180c3513fe155?d=identicon&s=25 Peter Bengtson (peter)
on 2006-12-29 00:46
(Received via mailing list)
Yes, there is. Take a look at LiteSpeed. It creates processes as
necessary, that is, dynamically.

	/ Peter
44a0b64c7d666735fb2711699ceb4c95?d=identicon&s=25 JD Harrington (Guest)
on 2006-12-29 00:54
(Received via mailing list)
On Dec 28, 2006, at 3:58 PM, subimage interactive wrote:

> Right now I don't think there is. You have to run at least 1
> process per Rails app. This is true with FCGI and Mongrel. CGI runs
> and completes its process after Rails does its business (I believe)
>
> The only hope for situations like this _might_ be the jRuby project.
>
> http://headius.blogspot.com/2006/04/beginning-of-j...
>

_why has been doing some interesting work with sandboxing in the ruby
interpreter that may help with this someday too:

http://redhanded.hobix.com/inspect/
theThrillingFreakyFreakySandboxHack.html

-JD Harrington
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 03:00
(Received via mailing list)
That's what I was afraid of..

Peter, I think you misunderstood the question; I believe LiteSpeed too
creates one process per app (key word: per app) and THEN creates more
as necessary as per your description. If you, indeed, didn't
misunderstand, and isn't mistaking, I'd love it if you could confirm
it.

However, I don't think it's possible, because I suspect this is an
issue with Rails itself, not the various dispatching solutions, since
the processes cache the model classes in memory, how could they
possibly contain several apps per process? Severe changes to Rails
itself would be necessary for a single Ruby process to be used *by
multiple Rails apps at once*. Again, I'm only almost certain of this,
if somebody with definite knowledge on the subject can confirm or deny
this, I'd really appreciate it.

Does anyone know if this issue is being investigated at all, if anyone
has addressed this concern before? As it stands now, Rails is an
excellent choice if you only run one or a couple of big apps on the
same server.. but for many smallish apps, its barely useable, which
IMHO is a damn shame.

Best regards,
Tomas Jogin
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-12-29 04:40
(Received via mailing list)
On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote:

> Does anyone know if this issue is being investigated at all, if anyone
> has addressed this concern before? As it stands now, Rails is an
> excellent choice if you only run one or a couple of big apps on the
> same server.. but for many smallish apps, its barely useable, which
> IMHO is a damn shame.

It's only a usability problem with respect to resources, and the only
way to measure that is against the entire pool of resources required
to create and maintain the application as well.

For instance, let's say that Ruby is 16 times as expensive in terms
of memory as something else. What is the cost of that memory compared
to the cost advantage (if any!) of development speed and maintainability
of the application itself?

Memory is not expensive these days, and it's getting less expensive
each and every day.

--
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 09:29
(Received via mailing list)
What does the development speed have to do with being able to run
multiple apps per process, or not being able to? I fail to see how the
two have any relation what so ever.
Eea7ad39737b0dbf3de38874e0a6c7d8?d=identicon&s=25 Justin Forder (Guest)
on 2006-12-29 12:45
(Received via mailing list)
Tomas Jogin wrote:
>
> What does the development speed have to do with being able to run
> multiple apps per process, or not being able to? I fail to see how the
> two have any relation what so ever.

Both contribute to the total cost of ownership of the application.

Rails may use more memory than other web technologies, but memory is
cheap - if Rails saves development and maintenance effort, and gets you
to market faster, that's an overall win.

regards

   Justin Forder
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 12:53
(Received via mailing list)
So, in what way are they mutually exclusive? How would it negatively
impact he development speed if Rails apps could share processes?

I'm not a newbie to Rails, I've been using it for over two years and
I'm quite familiar with the productivity gains. Nowhere have I claimed
otherwise. I'm just having a performance problem even though I have
small audiences and few users. If apps could share processes, it would
decrease costs significantly, since each server could be used with
less overhead.
2872eff1b6f35a3d12a3ccd572f3bf3f?d=identicon&s=25 Andre Nathan (Guest)
on 2006-12-29 13:59
(Received via mailing list)
Tomas, did you consider trying out mod_ruby?

Andre
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 14:21
(Received via mailing list)
Is mod_ruby even a viable alternative? I've never heard of anyone
using it for RoR? Actually I did *think* about it, but wrote it off
based on what I just said. Was that in haste?
Eea7ad39737b0dbf3de38874e0a6c7d8?d=identicon&s=25 Justin Forder (Guest)
on 2006-12-29 14:25
(Received via mailing list)
Tomas Jogin wrote:

> So, in what way are they mutually exclusive? How would it negatively
> impact he development speed if Rails apps could share processes?

In principle they are orthogonal. In practice, they are constrained by
the way Rails is at present.

Nobody has suggested that it would be a bad thing if a process could
host more than one Rails application - Dave Thomas has suggested it
would be good for Rails to have a 'container' that applications could be
deployed into, and Why's sandbox appears to be a step in that direction.

> I'm not a newbie to Rails, I've been using it for over two years and
> I'm quite familiar with the productivity gains. Nowhere have I claimed
> otherwise. I'm just having a performance problem even though I have
> small audiences and few users. If apps could share processes, it would
> decrease costs significantly, since each server could be used with
> less overhead.

I picked up on the memory aspect, because it is frequently discussed and
because Tom gave memory use as an example of resource use - but you seem
to be saying that you have performance problems relating to the number
of processes running, before memory becomes a problem. Can you say more
about this?

regards

   Justin
2872eff1b6f35a3d12a3ccd572f3bf3f?d=identicon&s=25 Andre Nathan (Guest)
on 2006-12-29 14:27
(Received via mailing list)
I'm using it for internal applications here and it's working fine.
Version 1.2.6 has a RailsDispatcher that addresses the problems that
occurred with the shared interpreters in previous versions.

I still haven't made it available for our customers, but it might be
worth giving it a try, since at least in theory it should do what you
need.

Regards,
Andre
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 14:40
(Received via mailing list)
> of processes running, before memory becomes a problem. Can you say more
> about this?

I'm the same guy. I'm asking questions related to how to improve the
per-server performance of Rails. Since I'm running several apps, the
server starts a new Ruby process for each app. This means I have
thirty or more Ruby processes running. However, just one or two
processes would suffice to handle the combined load. That means the
server uses 15 to 30 times more processes than necessary, simply
because of how Rails internals work. If Rails apps could share
processes, I would get 15-30 times more performance or more PER
SERVER. That's one of them... "limitations", to misquote Bush.

So I'm here to ask if anyone else has run into this particular problem
of running many small apps and having the performance sucked out of
the server NOT due to overwhelming amounts of visitors, but because
apps can't share processes.

That's all. I'm already aware of the productivity gains of using
Rails, have been for over two years.
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 14:50
(Received via mailing list)
That's very interesting. I just read a blog post by Shugo regarding
the topic:
http://blog.shugo.net/articles/2005/08/03/running-...

Running Rails on mod_ruby, does it come with any pitfalls or
limitations?

Regards,
Tomas
2872eff1b6f35a3d12a3ccd572f3bf3f?d=identicon&s=25 Andre Nathan (Guest)
on 2006-12-29 15:08
(Received via mailing list)
Yes, I decided to try it after reading Shugo's blog.

The only pitfall I found so far is that everything in your application
is "packed" into the Apache::RailsDispatcher::CURRENT_MODULE module. I
had some code that depended on the the class of a given object to
choose the action it would take, and I had to fix it by using
"self.class.to_s.demodulize" instead of just "self.class.to_s" to get
just "Foo" instead of "Apache::RailsDispatcher::CURRENT_MODULE::Foo".
It's no big issue after you realize what's going on, I guess.

Andre
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-29 15:32
(Received via mailing list)
Thanks, that's very interesting. I'll have to investigate this further.

Best regards,
Tomas Jogin
Eea7ad39737b0dbf3de38874e0a6c7d8?d=identicon&s=25 Justin Forder (Guest)
on 2006-12-29 15:50
(Received via mailing list)
Tomas Jogin wrote:
>> to be saying that you have performance problems relating to the number
>> of processes running, before memory becomes a problem. Can you say more
>> about this?
>
> I'm the same guy.

Tom = Tom Mornini, the person whose answer caused you to ask why he
brought up the issue of speed of development.

> I'm asking questions related to how to improve the
> per-server performance of Rails. Since I'm running several apps, the
> server starts a new Ruby process for each app. This means I have
> thirty or more Ruby processes running. However, just one or two
> processes would suffice to handle the combined load. That means the
> server uses 15 to 30 times more processes than necessary, simply
> because of how Rails internals work. If Rails apps could share
> processes, I would get 15-30 times more performance or more PER
> SERVER. That's one of them... "limitations", to misquote Bush.

You would get the same performance with much less memory use.

Having 30 idle processes should nave negligible impact on performance,
unless their memory use is causing paging or swapping.

> So I'm here to ask if anyone else has run into this particular problem
> of running many small apps and having the performance sucked out of
> the server NOT due to overwhelming amounts of visitors, but because
> apps can't share processes.
>
> That's all. I'm already aware of the productivity gains of using
> Rails, have been for over two years.

Has anyone suggested you are not?

regards

   Justin
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-12-29 22:13
(Received via mailing list)
I wasn't suggesting that they are mutually exclusive or that I wouldn't
like the situation to be different.

But, right now, they *are* mutually exclusive: There's no way to use
Rails (and therefore gain it's benefits) without incurring this cost.

--
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
81e965af3070ffa9c7979cb5f2494c60?d=identicon&s=25 Hank Marquardt (Guest)
on 2006-12-29 23:06
(Received via mailing list)
I feel your pain and understand your issue.

I think however, that this is part of being 'opinionated software' ...
it
really is about developer productivity, not server productivity.
Again, I
know your asking to improve server productivity and it's a nobel cause
... I
just don't see the rails core guys caring or wanting to work on it
anytime
soon.

Second, it's also about using the right tool for the job and rails just
isn't the right tool for web 'pages' or really small apps to be shared
hosted with hundreds of other accounts.   Sure, we all *want* to use it
in
that space, because we know it and it is great for productivity, but the
very overhead you're discussing is why it's the wrong tool in
'small'space.

I'll be right there with you cheering on the solution when/if it comes,
but
for right now, the answer you seek doesn't exist.
032fdb4cd4a3c65ebb77846dfa724679?d=identicon&s=25 Joe Noon (joenoon)
on 2006-12-30 07:13
(Received via mailing list)
> 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
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2006-12-30 08:55
(Received via mailing list)
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:
http://www.litespeedtech.com/support/forum/archive...
74e21b54f21ba89e663180c3513fe155?d=identicon&s=25 Peter Bengtson (peter)
on 2006-12-30 09:55
(Received via mailing list)
Tomas, there is no *point* in sharing Ruby processes, when they are
spawned and killed according to need.
032fdb4cd4a3c65ebb77846dfa724679?d=identicon&s=25 Joe Noon (joenoon)
on 2006-12-30 11:23
(Received via mailing list)
> On 30 dec 2006, at 08.52, Tomas Jogin wrote:
>
> >
> > 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.

On 12/30/06, Peter Bengtson <peter@peterbengtson.com> wrote:
>
> 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.
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2007-01-01 13:37
(Received via mailing list)
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.

Regards,
Tomas Jogin
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-01-01 15:46
Joe Noon wrote:
> 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.

Peter Bengtson wrote:
> Tomas, there is no *point* in sharing Ruby processes, when they are
> spawned and killed according to need.

Spawning a Rails process is about as expensive as handling 20 requests.
Let's say you have 60 apps, each gets hit twice per minute with uniform
distribution, so the server has to handle about 2 request per second. No
big deal. But if you do on-demand-spawning, it has to handle the load
equivalent of 42 requests per second.

Of course, this is a worst-case scenario, but you get the point.
On-demand-spawning is no silver bullet. In many cases it is better to
just load everything and leave it to the OS to swap unneeded
applications to the disk if memory gets low.
74e21b54f21ba89e663180c3513fe155?d=identicon&s=25 Peter Bengtson (peter)
on 2007-01-01 16:41
(Received via mailing list)
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.

	/ Peter
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-01-01 16:53
Peter Bengtson wrote:
> Well, if processes were spawned every time they are needed and then
> killed again after use, each time, you would have something very
> inefficient.

> 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.

>>> Tomas, there is no *point* in sharing Ruby processes, when they are
>>> spawned and killed according to need.

I just wanted to show you that there IS a point in sharing ruby
processes between apps. When you have a high number of small apps that
get hit with roughly equal probability, you gain almost nothing with
dynamic process spawning. That's a common scenario for 99ct mass web
hosters.
433024a5a3f9fc91664c8170af1c7350?d=identicon&s=25 Tomas Jogin (Guest)
on 2007-01-01 20:35
(Received via mailing list)
We're running Apache 1.3.something plus FastCGI, is this setup
especially bad at handling Ruby processes?

Is LiteSpeed recommended for serving static content too or just
dynamic stuff via proxy?
A84d51d60791f8e0fb6d27a8a8b2a96e?d=identicon&s=25 Neil Wilson (neilw)
on 2007-01-02 14:07
(Received via mailing list)
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.
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-01-02 14:16
Neil Wilson wrote:
> For ease of management though, I would suggest using Mongrel rather
> than FCGI. It's just a lot easier when everything is talking HTTP.

If memory IS an issue then that's not a good idea, Mongrel uses almost
twice as much as FCGI/LSAPI.
This topic is locked and can not be replied to.