Re: Modperl/Apache deficiencies... Memory usage.y

[Leslie Mikesell <le...@mcs.net>]

According to shane@isupportlive.com:

> Does anyone know of any program which has been developed like this?
> Basically we'd be turning the "module of apache" portion of mod_perl
> into a front end to the "application server" portion of mod_perl that
> would do the actual processing.

This is basically what you get with the 'two-apache' mode.

> It seems quite logical that something
> like this would have been developed, but possibly not.  The seperation
> of the two components seems like it should be done, but there must be
> a reason why no one has done it yet... I'm afraid this reason would be
> the apache module API doesn't lend itself to this.

The reason it hasn't been done in a threaded model is that perl
isn't stable running threaded yet, and based on the history
of making programs thread-safe, I'd expect this to take at
least a few more years.  But, using a non-mod-perl front
end proxy with ProxyPass and RewriteRule directives to hand
off to a mod_perl backend will likely get you a 10-1 reduction
in backend processes and you already know the configuration
syntax for the second instance.

 Les Mikesell
   les@mcs.com

Re: Modperl/Apache deficiencies... Memory usage.y

[sh...@isupportlive.com]

On Sat, Apr 15, 2000 at 01:39:38PM -0500, Leslie Mikesell wrote:
> According to shane@isupportlive.com:
> 
> > Does anyone know of any program which has been developed like this?
> > Basically we'd be turning the "module of apache" portion of mod_perl
> > into a front end to the "application server" portion of mod_perl that
> > would do the actual processing.
> 
> This is basically what you get with the 'two-apache' mode.

To be frank... it's not.  Not even close.  Especially in the case that
the present site I'm working on where they have certain boxes for
dynamic, others for static.  This is usefull when you have one box
running dynamic/static requests..., but it's not a solution, it's a
work around.  (I should say we're moving to have some boxes static
some dynamic... at present it's all jumbled up ;-()

> 
> > It seems quite logical that something
> > like this would have been developed, but possibly not.  The seperation
> > of the two components seems like it should be done, but there must be
> > a reason why no one has done it yet... I'm afraid this reason would be
> > the apache module API doesn't lend itself to this.
> 
> The reason it hasn't been done in a threaded model is that perl
> isn't stable running threaded yet, and based on the history
> of making programs thread-safe, I'd expect this to take at
> least a few more years.  But, using a non-mod-perl front
> end proxy with ProxyPass and RewriteRule directives to hand
> off to a mod_perl backend will likely get you a 10-1 reduction
> in backend processes and you already know the configuration
> syntax for the second instance.

Well, now your discussing threaded perl... a whole seperate bag of
tricks :).  That's not what I'm talking about... I'm talking about
running a standard perl inside of a threaded enviro.  I've done this,
and thrown tens of thousands of requests at it with no problems.  I
believe threaded perl is an attempt to allow multiple simultaneous
requests going into a single perl engine that is "multi threaded".
There are problems with this... and it's difficult to accomplish, and
alltogether a slower approach than queing because of the context
switching type overhead.  Not to mention the I/O issue of this...
yikes! makes my head spin.

Thanks,
Shane.
> 
>  Les Mikesell
>    les@mcs.com