mod_perl_fast anyone?

[Doug MacEachern <do...@osf.org>]

Thanks to a kick start from someone I used to work with, I've made it to the
"future" section of mod_perl's readme.  When the server starts, a perl
script is picked up via a 'PerlScript' config directive, parsed and run.
So, the script should consist mostly of subroutines, along with use()'s and
require()'s for loading perl modules.  It may also include code you only
want to happen once, such as a opening a database connection.  
Then, a per_dir_config PerlResponseSub command tells the module which
subroutine to call for handling the request.  

Here are some times, using perl's Benchmark module and libwww-perl as the
client.  Each script, loads the DBI, CGI, and LWP perl modules.  A database
connection is opened to an mSQL database, one at server start-up for the
'embedded' script, one per request for the 'cgi' script.  
Each script preforms the same database query, and sends results back to the
client.
(Each 'iteration' is an http request).
 
Benchmark: timing 1 iterations of cgi, embedded...
       cgi:  2 secs 
  embedded:  0 secs 

Benchmark: timing 5 iterations of cgi, embedded...
       cgi: 10 secs 
  embedded:  2 secs 

Benchmark: timing 10 iterations of cgi, embedded...
       cgi: 18 secs 
  embedded:  3 secs 

Benchmark: timing 15 iterations of cgi, embedded...
       cgi: 27 secs
  embedded:  5 secs

Quite a difference.

Now, which direction should we go here?

Two modules, each taking a different approach?
One module that can handle both approaches?
    
Keep in mind, with mod_perl's current implementation, *any* number of
different, non-related, would-never-work-together scripts can be handled.  
With this idea of parsing and running the code at start-up, means you have
*one* main script, which may choose to pull in other perl code.  So, each
piece of code needs to get along with each other.  Also, whenever a change
is made to your script, the server must be restarted for that change to take
effect.

For my testing, I have two modules, they are both small, since they can
share Apache.xs where most of the code lives.
An area unexplored by myself is having more that one interpreter living in
the same process.  Building perl with -DMULTIPLICITY is supposed to do the
trick, but I'm not sure if this is all that needs to happen in this case.

Please let me have your thoughts on all this...

-Doug