mod-perl:
##########
http://www.perl.com/pub/2002/02/26/whatismodperl.html
http://www.perl.com/pub/2002/03/22/modperl.html
Having the Perl interpreter embedded in the server saves the very considerable overhead of starting an external interpreter for any HTTP request that needs to run Perl code.
At least as important is code caching: the modules and scripts are loaded and compiled only once, when the server is first started. Then for the rest of the server's life the scripts are served from the cache, so the server only has to run the pre-compiled code. In many cases, this is as fast as running compiled C programs.
The primary advantages of mod_perl are power and speed
You have full access to the inner workings of the Web server and you can intervene at any stage of HTTP request processing
There are big savings in startup and compilation times.
Difference between Apache::Registry, Apache::PerlRun ?
################################################################
Speed Wise :
Apache::Registry > Apache::PerlRun > Perl CGI
The Apache::PerlRun Class
###########################
The Apache::PerlRun handler is intended for Perl CGI scripts that depend strongly on the traditional
one-process-per-execution CGI model and cannot deal with being invoked repeatedly in the same process.
For example,
a script that depends on a lot of global variables being uninitialized when it starts up is unlikely to work properly under Apache::Registry.
Like Apache::Registry, Apache::PerlRun manages a directory of CGI scripts, launching them when they are requested.
However, unlike Apache::Registry, Apache::PerlRun module does not cache compiled scripts between runs. A script is loaded and compiled freshly each time it is requested.
However, Apache::PerlRun still avoids the overhead of starting a new Perl interpreter for each CGI script,
so it's faster than traditional Perl CGI scripting but slower than Apache::Registry or vanilla Apache API modules.
It offers a possible upgrade path for CGI scripts: move the script to Apache::PerlRun initially to get a modest performance bump.
This gives you time to rework the script to make it globally clean so that it can run under Apache::Registry for the full performance benefit.
The configuration section for running Apache::PerlRun is similar to Apache::Registry:
Alias /perl-run/ /home/www/perl-run/
<Location /perl>
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
# optional
PerlSendHeader On
</Location>
The Apache::PerlRun handler is only a small part of the picture. The rest of the Apache::PerlRun class provides subclassable methods that implement the functionality of Apache::Registry.
The Apache::PerlRun handler simply uses a subset of these methods; other modules may override certain methods to implement the Apache::Registry enviroment with a few twists. However, these Apache::PerlRun class methods were not fully defined when this book was going to press.
The Apache::Registry Class
##############################
The Apache::Registry class is essentially a CGI environment emulator that allows many CGI scripts to run without modification under mod_perl. Because there are many differences between CGI and the Apache API, Apache::Registry has to do a great deal of work to accomplish this sleight of hand.
It loads the scripts in its designated directory, compiles them, and stores them persistently in a memory structure. Before Apache::Registry runs a script, mod_perl will set up the various CGI environment variables, provided PerlSetupEnv is configured to On, which is the default.
When the PerlSendHeader directive is On, mod_perl monitors the text printed by the script, intercepts the HTTP header, and passes it through send_cgi_header(). It also arranges for STDIN to be read from the request object when the script attempts to process POST data.
Apache::Registry also monitors the modification dates of the script files it is responsible for and reloads them if their timestamp indicates they have been changed more recently than when they were last compiled.
Despite its complexity, Apache::Registry is easy to set up. The standard configuration consists of an Alias directive and a <Location> section:
Alias /perl/ /home/www/perl
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
# optional
PerlSendHeader On
</Location>
After restarting the server, you can place any (well, almost any) Perl CGI script into /home/www/perl (or the location of your choice) and make it executable. It runs just like an ordinary CGI script but will load much faster. The behavior of Apache::Registry can be tuned with the following directives:
PerlTaintCheck
When set to On, mod_perl will activate Perl taint checks on all the scripts under its control. Taint checks cause Perl to die with a fatal error if unchecked user-provided data (such as the values of CGI variables) is passed to a potentially dangerous function, such as exec(), eval(), or system().
PerlSendHeader
When set to On, mod_perl will scan for script output that looks like an HTTP header and automatically call send_http_header(). Scripts that send header information using CGI. pm's header() function do not need to activate PerlSendHeader. While scripts that use CGI.pm's header() will still function properly with PerlSendHeader On, turning it Off will save a few CPU cycles.
PerlFreshRestart
If PerlFreshRestart is set to On, mod_perl will flush its cache and reload all scripts when the server is restarted. This is very useful during module development to immediately see the changes to the source code take effect.
PerlWarn
If the script mentions the -w switch on its #! line, Apache::Registry will turn Perl warnings on by setting the $^W global to a nonzero value. The Perl-Warn directive can be configured to On to turn on warnings for all code inside the server.
Apache::Registry has several debug levels which write various informational messages to the server error log.
Apache::Registry scripts can change the debug level by importing Apache::Debug with its level pragma:
use Apache::Debug level => $level;
The debug level is a bit mask generated by ORing together some combination of the following values:
1 Make a note in the error log whenever the module is recompiled
2 Call Apache::Debug::dump() on errors
4 Turn on verbose tracing
The current value of the debug level can be found in the package global $Apache::Registry::Debug. You should not set this value directly, however. See Chapter 2, A First Module, for more hints on debugging Apache::Registry scripts.
===============================================================================================================
##########
http://www.perl.com/pub/2002/02/26/whatismodperl.html
http://www.perl.com/pub/2002/03/22/modperl.html
Having the Perl interpreter embedded in the server saves the very considerable overhead of starting an external interpreter for any HTTP request that needs to run Perl code.
At least as important is code caching: the modules and scripts are loaded and compiled only once, when the server is first started. Then for the rest of the server's life the scripts are served from the cache, so the server only has to run the pre-compiled code. In many cases, this is as fast as running compiled C programs.
The primary advantages of mod_perl are power and speed
You have full access to the inner workings of the Web server and you can intervene at any stage of HTTP request processing
There are big savings in startup and compilation times.
Difference between Apache::Registry, Apache::PerlRun ?
################################################################
Speed Wise :
Apache::Registry > Apache::PerlRun > Perl CGI
The Apache::PerlRun Class
###########################
The Apache::PerlRun handler is intended for Perl CGI scripts that depend strongly on the traditional
one-process-per-execution CGI model and cannot deal with being invoked repeatedly in the same process.
For example,
a script that depends on a lot of global variables being uninitialized when it starts up is unlikely to work properly under Apache::Registry.
Like Apache::Registry, Apache::PerlRun manages a directory of CGI scripts, launching them when they are requested.
However, unlike Apache::Registry, Apache::PerlRun module does not cache compiled scripts between runs. A script is loaded and compiled freshly each time it is requested.
However, Apache::PerlRun still avoids the overhead of starting a new Perl interpreter for each CGI script,
so it's faster than traditional Perl CGI scripting but slower than Apache::Registry or vanilla Apache API modules.
It offers a possible upgrade path for CGI scripts: move the script to Apache::PerlRun initially to get a modest performance bump.
This gives you time to rework the script to make it globally clean so that it can run under Apache::Registry for the full performance benefit.
The configuration section for running Apache::PerlRun is similar to Apache::Registry:
Alias /perl-run/ /home/www/perl-run/
<Location /perl>
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
# optional
PerlSendHeader On
</Location>
The Apache::PerlRun handler is only a small part of the picture. The rest of the Apache::PerlRun class provides subclassable methods that implement the functionality of Apache::Registry.
The Apache::PerlRun handler simply uses a subset of these methods; other modules may override certain methods to implement the Apache::Registry enviroment with a few twists. However, these Apache::PerlRun class methods were not fully defined when this book was going to press.
The Apache::Registry Class
##############################
The Apache::Registry class is essentially a CGI environment emulator that allows many CGI scripts to run without modification under mod_perl. Because there are many differences between CGI and the Apache API, Apache::Registry has to do a great deal of work to accomplish this sleight of hand.
It loads the scripts in its designated directory, compiles them, and stores them persistently in a memory structure. Before Apache::Registry runs a script, mod_perl will set up the various CGI environment variables, provided PerlSetupEnv is configured to On, which is the default.
When the PerlSendHeader directive is On, mod_perl monitors the text printed by the script, intercepts the HTTP header, and passes it through send_cgi_header(). It also arranges for STDIN to be read from the request object when the script attempts to process POST data.
Apache::Registry also monitors the modification dates of the script files it is responsible for and reloads them if their timestamp indicates they have been changed more recently than when they were last compiled.
Despite its complexity, Apache::Registry is easy to set up. The standard configuration consists of an Alias directive and a <Location> section:
Alias /perl/ /home/www/perl
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
# optional
PerlSendHeader On
</Location>
After restarting the server, you can place any (well, almost any) Perl CGI script into /home/www/perl (or the location of your choice) and make it executable. It runs just like an ordinary CGI script but will load much faster. The behavior of Apache::Registry can be tuned with the following directives:
PerlTaintCheck
When set to On, mod_perl will activate Perl taint checks on all the scripts under its control. Taint checks cause Perl to die with a fatal error if unchecked user-provided data (such as the values of CGI variables) is passed to a potentially dangerous function, such as exec(), eval(), or system().
PerlSendHeader
When set to On, mod_perl will scan for script output that looks like an HTTP header and automatically call send_http_header(). Scripts that send header information using CGI. pm's header() function do not need to activate PerlSendHeader. While scripts that use CGI.pm's header() will still function properly with PerlSendHeader On, turning it Off will save a few CPU cycles.
PerlFreshRestart
If PerlFreshRestart is set to On, mod_perl will flush its cache and reload all scripts when the server is restarted. This is very useful during module development to immediately see the changes to the source code take effect.
PerlWarn
If the script mentions the -w switch on its #! line, Apache::Registry will turn Perl warnings on by setting the $^W global to a nonzero value. The Perl-Warn directive can be configured to On to turn on warnings for all code inside the server.
Apache::Registry has several debug levels which write various informational messages to the server error log.
Apache::Registry scripts can change the debug level by importing Apache::Debug with its level pragma:
use Apache::Debug level => $level;
The debug level is a bit mask generated by ORing together some combination of the following values:
1 Make a note in the error log whenever the module is recompiled
2 Call Apache::Debug::dump() on errors
4 Turn on verbose tracing
The current value of the debug level can be found in the package global $Apache::Registry::Debug. You should not set this value directly, however. See Chapter 2, A First Module, for more hints on debugging Apache::Registry scripts.
===============================================================================================================
No comments:
Post a Comment