embedded Perl process in Apache using mod_perl

[ccc31807]

Could someone give a simple and short explanation of what it means to
say that mod_perl embeds a Perl process in Apache?

I understand that classical CGI passes requests for a script to Perl,
which fires up a Perl process, runs the script, returns a value, and
shuts down. I also understand that FastCGI does the same thing except
that the Perl process doesn't start and stop with each request but
remains running in the background.

However, I don't understand t mechanism of an embedded Perl process in
mod_perl, and the question seems so elementary that the documentation
doesn't address it. Or maybe I just haven't read the right
documentation.

Thanks, CC.

 

[Peter J. Holzer]

Could someone give a simple and short explanation of what it means to
say that mod_perl embeds a Perl process in Apache?

I understand that classical CGI passes requests for a script to Perl,
which fires up a Perl process, runs the script, returns a value, and
shuts down.

That's at least ambiguously formulated.

I also understand that FastCGI does the same thing except
that the Perl process doesn't start and stop with each request but
remains running in the background.

However, I don't understand t mechanism of an embedded Perl process in
mod_perl, and the question seems so elementary that the documentation
doesn't address it.

In CGI, the web server

* sets some environment variables from the request header (see
RFC 3875, section 4.1 for details)
* starts the CGI program as a new process, with stdin and stdout
connected to the server (usually via pipes).
* If there is a request body (e.g. in a POST or PUT request) it is sent
to the stdin of the newly created process.
* The response of CGI program is read from the pipe connected to the
program's stdout and (with minor changes) passed on to the client.

The CGI program may or may not be written in Perl. The server doesn't
know or care - it does not invoke a perl interpreter, it invokes the CGI
program (on Unix systems the kernel then determines the type of the
executable and invokes a suitable interpreter if necessary).

In FastCGI:

* The FCGI program runs as an independent server process which listens
on a (unix or tcp) socket for requests.
* Startup and Shutdown of this process is often managed by the web
server, but not necessarily.
* The web server uses a special protocol to send requests to and read
responses from the FCGI process.

Again, a FastCGI program may be written in any language, the web server
doesn't care. In fact, the FastCGI program may even run on a different
host!

In mod_perl:

* The web server has an embedded perl interpreter, i.e., it is linked
with libperl and knows how to call this interpreter (this is a
(C) function call, not a program invokation).
* The perl interpreter has access to an API, so that it can access
at the request and response data.
* At or before the first request, the web server/perl interpreter
compiles the Perl script (possibly including some wrapper code),
so we now have one or more compiled perl subs/methods.
* For each request, the perl bytecode interpreter runs the appropriate
sub/method.

Here the web server does know that the code is written in Perl - it
needs to because it needs it interpret it itself.

hp

 

[Wanna-Be Sys Admin]

Could someone give a simple and short explanation of what it means to
say that mod_perl embeds a Perl process in Apache?

I understand that classical CGI passes requests for a script to Perl,
which fires up a Perl process, runs the script, returns a value, and
shuts down. I also understand that FastCGI does the same thing except
that the Perl process doesn't start and stop with each request but
remains running in the background.

However, I don't understand t mechanism of an embedded Perl process in
mod_perl, and the question seems so elementary that the documentation
doesn't address it. Or maybe I just haven't read the right
documentation.

Thanks, CC.

mod_perl knows to parse the text in the file as a script (look or try
to, depending) without spawning a new process outside of the already
running httpd process. It saves overhead from not spawning an
additional process (other than additionally needed httpd processes
themselves, possibly, but that's about the request, rather than the
script). Be aware that mod_perl needs to run the process as the global
web server user, not the user that it'd run as if you had a CGI
wrapper, such as Apache would normally use, which can be better or
worse depending if you're in a shared or trusted server environment.
Also, the possibility of memory leaks causing issues where a CGI
process is separate and can be controlled individually, along with
other CGI scripts. Depending on the module and framework, a process
can wait for connections without opening a new call/process, etc. to
handle future or multiple requests, therein saving more resources than
just avoiding CGI overhead. I'd rather recommend FastCGI over mod_perl
for reasons of security on a shared user server environment, unless you
each run your own instance of the web service anyway.