Beginner question re. mod_perl

Beginner question re. mod_perl

am 17.05.2008 17:04:31 von kropotkin

Hi

I'm just trying to understand the basics, having set up my server to run
mod_perl.

say a request is made which via a Location directive and PerlResponseHandler
directive is handled by my Perl module say Handler1.pm , ok a child process
is spawned with mod_perl embedded which also loads and compiles Handler1.pm.
Ok. If another request is made to Handler1.pm subject to the child process
not having been killed by the parent I understand that this same child
process will handle this new request. But if a request is made to
Handler2.pm would this always result in a new child process or could the
first process handle this request as well - just adding the code for
Handler2.pm to its process space?

This matters because I am setting up multiple web sites and I am wondering
if it is better to have just a few PerlHandlers or to have different ones
per site.

with thanks for your answer

Kropotkin
--
View this message in context: http://www.nabble.com/Beginner-question-re.-mod_perl-tp17292 733p17292733.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Beginner question re. mod_perl

am 17.05.2008 18:20:47 von torsten.foertsch

On Sat 17 May 2008, kropotkin wrote:
> say a request is made which via a Location directive and
> PerlResponseHandler directive is handled by my Perl module say Handler1.pm
> , ok a child process is spawned with mod_perl embedded which also loads and
> compiles Handler1.pm. Ok. If another request is made to Handler1.pm subject
> to the child process not having been killed by the parent I understand that
> this same child process will handle this new request. But if a request is
> made to
> Handler2.pm would this always result in a new child process or could the
> first process handle this request as well - just adding the code for
> Handler2.pm to its process space?

I assume you are using the prefork MPM.

At first try to figure out what the "pre" in prefork-MPM means. Apache does
not create its worker processes at request time but always has a few idle
processes hanging around waiting for requests. So at request time no process
has to be forked off.

Now you have configured your request to be handled by mod_perl. In this case a
perl interpreter resides inside the apache processes. It works similar to the
following code snippet:

$|=1;
$/="\n\n";
print "enter a code block> ";
while(<>) {
print eval $_;
warn "$@" if($@);
print "enter a code block> ";
}

This piece of code prints a prompt and waits for you to enter a code chunk. An
empty input line finalizes the code chunk. Then the perl interpreter
evaluates the chunk and prints the result. If there was an error a warning
message is printed. Then comes the next prompt.

So what happens if you enter a chunk like:

use Data::Dumper;
Dumper({a=>1, b=>[qw!a b c!]});

The Perl interpreter loads the Data::Dumper module and calls a function from
it.

Next time you enter the same chunk the perl interpreter will notice that the
Data::Dumper module is already loaded and only call the function.

Next time you may enter this piece:

use LWP::UserAgent;
LWP::UserAgent->new->get("http://foertsch.name/")->content;

Now the perl interpreter loads the LWP::UserAgent module but the Data::Dumper
module still remains in core because the perl interpreter is the same.

This example shows a few points:

1) no extra process is forked for each request. This is the main advantage of
mod_perl over CGI where each request is processed by a separate process.

2) Once a module is loaded it remains in memory no matter whether it is used
again. So, if the current request doesn't need a module that modules memory
is wasted.

3) Modules may interact with one another. This may be wanted or not. But
modules must be aware that they are not alone.

4) you have a long running perl interpreter. That means opened files that are
forgotten by a piece of code remain open. The same is true for other things
concerning the process as a whole like chdir, signal handlers/masks etc.

Now mod_perl works similar to this little example. When a request enters an
apache worker and it decides to hand it over to mod_perl then perl
interpreter just executes a piece of code. Each request that hits that worker
process uses the same perl interpreter.

With the worker MPM the situation is a bit more complex but the idea of the
argument remains valid. One perl interpreter handles many requests.

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net

Re: Beginner question re. mod_perl

am 17.05.2008 18:52:48 von Sean Davis

On Sat, May 17, 2008 at 11:04 AM, kropotkin wrote:
>
> Hi
>
> I'm just trying to understand the basics, having set up my server to run
> mod_perl.
>
> say a request is made which via a Location directive and PerlResponseHandler
> directive is handled by my Perl module say Handler1.pm , ok a child process
> is spawned with mod_perl embedded which also loads and compiles Handler1.pm.
> Ok. If another request is made to Handler1.pm subject to the child process
> not having been killed by the parent I understand that this same child
> process will handle this new request. But if a request is made to
> Handler2.pm would this always result in a new child process or could the
> first process handle this request as well - just adding the code for
> Handler2.pm to its process space?

All children will handle any request. New children are spawned in
response to a need rather than a new "type" of request.

> This matters because I am setting up multiple web sites and I am wondering
> if it is better to have just a few PerlHandlers or to have different ones
> per site.

If by different sites, you mean different apache servers, then it
doesn't make much difference. However, if you are talking about
virtual hosting, again any child can handle the request.

Sean