embedded Perl process in Apache using mod_perl

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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

Thanks, CC.

Re: embedded Perl process in Apache using mod_perl

On 01/18/2010 10:03 AM, ccc31807 wrote:
Quoted text here. Click to load it

Mod_perl adds itself to apache's "core." Apache--the webserver, now can
run Perl code. This means that it's no longer necessary for Apache to
invoke an external process (slow) to interpret Perl code. When Apache
needs to do so, it calls /itself/.

That arrangement allows for a dramatic speedup in processing Perl
scripts while adding considerable complexity as well. Apache's "core"
isn't simple.

Re: embedded Perl process in Apache using mod_perl

Quoted text here. Click to load it

That's at least ambiguously formulated.

Quoted text here. Click to load 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

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

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


Re: embedded Perl process in Apache using mod_perl

Quoted text here. Click to load it

See perlembed. In simple terms, perl is built as a library (usually
called libperl.so), which provides functions to create and manipulate
Perl interpreters. perl(1) itself is a very simple program that links
libperl, and uses it to create, run and destroy a single interpreter.
mod_perl is an Apache DSO that also links libperl, and generally creates
more than one interpreter. (One consequence of this is that if you were
to delete /usr/bin/perl, mod_perl wouldn't be affected.)


Re: embedded Perl process in Apache using mod_perl

ccc31807 wrote:

Quoted text here. Click to load it

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.
Not really a wanna-be, but I don't know everything.

Site Timeline