view release on metacpan or  search on metacpan

README.html  view on Meta::CPAN

<HR>
<H2><A NAME="Apache_Configuration">Apache Configuration</A></H2>
<P>
Once mod_persistentperl is installed, it has to be configured to be used
for your perl scripts. There are two methods.

<P>
Warning! The instructions below may compromise the security of your web
site. The security risks associated with PersistentPerl are similar to
those of regular CGI. If you don't understand the security implications of
the changes below then don't make them.

<OL>
<LI><STRONG><A NAME="item_Path_Configuration">Path Configuration</A></STRONG>
<P>
This is similar to the way <EM>/cgi-bin</EM> works - everything under this path is handled by PersistentPerl. Add the
following lines near the top of your httpd.conf - this will cause all
scripts in your cgi-bin directory to be handled by PersistentPerl when they
are accessed as <EM>/perperl/script-name</EM>.

<P>
<PRE>    Alias /perperl/ /home/httpd/cgi-bin/
    &lt;Location /perperl&gt;
        SetHandler persistentperl-script
        Options ExecCGI
        allow from all
    &lt;/Location&gt;
</PRE>
<LI><STRONG><A NAME="item_File_Extension_Configuration">File Extension Configuration</A></STRONG>
<P>
This will make PersistentPerl handle all files with a certain extension,
similar to the way .cgi files work. Add the following lines near the top of
your httpd.conf file - this will set up the file extension ``.perperl'' to
be handled by PersistentPerl.

<P>
<PRE>    AddHandler persistentperl-script .perperl
    &lt;Location /&gt;
        Options ExecCGI
    &lt;/Location&gt;
</PRE>
</OL>
<P>
<HR>
<H1><A NAME="FREQUENTLY_ASKED_QUESTIONS">FREQUENTLY ASKED QUESTIONS</A></H1>
<DL>
<DT><STRONG><A NAME="item_How">How does the perperl front end connect to the back end process?</A></STRONG><DD>
<P>
Via a Unix socket in <EM>/tmp</EM>. A queue is kept in a shared file in <EM>/tmp</EM>
that holds an entry for each process. In that queue are the pids of the
perl processes waiting for connections. The frontend pulls a process out of
this queue, connects to its socket, sends over the environment and argv,
and then uses this socket for stdin/stdout to the perl process.

</DL>
<DL>
<DT><STRONG><A NAME="item_If">If another request comes in while PersistentPerl script is running, does the client
have to wait or is another process started?  Is there a way to set a limit
on how many processes get started?</A></STRONG><DD>
<P>
If another request comes while all the perl processes are busy, then
another perl process is started. Just like in regular perl there is
normally no limit on how many processes get started. But, the processes are
only started when the load is so high that they're necessary. If the load
goes down, the processes will die off due to inactivity, unless you disable
the timeout.

<P>
Starting in version 1.8.3 an option was added to limit the number of perl
backends running. See <STRONG>MaxBackends</STRONG> in <A HREF="#Options_Available">Options Available</A>
above.

</DL>
<DL>
<DT><STRONG>How much of perl's state is kept when perperl starts another request?
Do globals keep their values?  Are destructors run after the request?</STRONG><DD>
<P>
Globals keep their values. Nothing is destroyed after the request.
STDIN/STDOUT/STDERR are closed -- other files are not.  <CODE>%ENV</CODE> and <CODE>@ARGV</CODE>
are the only globals changed between requests.

</DL>
<DL>
<DT><STRONG>How can I make sure perperl restarts when I edit a perl library used
by the CGI?</STRONG><DD>
<P>
Do a touch on the main cgi file that is executed. The mtime on the main
file is checked each time the front-end runs.

</DL>
<DL>
<DT><STRONG><A NAME="item_Do">Do I need to be root to install and/or run PersistentPerl?</A></STRONG><DD>
<P>
No, root is not required.

</DL>
<DL>
<DT><STRONG>How can I determine if my perl app needs to be changed to work with
perperl?  Or is there no modification necessary?</STRONG><DD>
<P>
You may have to make modifications.

<P>
Globals retain their values between runs, which can be good for keeping
persistent database handles for example, or bad if your code assumes
they're undefined.

<P>
Also, if you create global variables with ``my'', you shouldn't try to
reference those variables from within a subroutine - you should pass them
into the subroutine instead. Or better yet just declare global variables
with ``use vars'' instead of ``my'' to avoid the problem altogether.

<P>
Here's a good explanation of the problem - it's for mod_perl, but the same
thing applies to persistentperl:

<P>
<PRE>    <A HREF="http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___Scoped_Variable_in_Nested_Subroutines">http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___Scoped_Variable_in_Nested_Subroutines</A>
</PRE>
<P>