You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Chris Thorman <ct...@innx.com> on 2000/06/20 08:21:22 UTC

Pre-compiling Embperl pages without Executing?

Hi,

The docs at 

http://perl.apache.org/embperl/Faq.pod.7.html#How_can_I_pre_compile_pages_so

... helpfully point out that calling Execute on your .epl pages at server startup time pre-compiles those pages into static shared memory which all subsequent child processes will share.  

I have a startup script that does this and it works well.

But there's a problem.  

Execute seems to actually want to RUN, not just compile and cache all the code in the pages as well.  So if any application on the site encounters a run-time error, it makes Apache startup fail.

This is a problem if I push a site where someone might be in the middle of editing some code in a private area, then need to stop and restart the servers and their code won't compile, preventing the server from starting.


A proposed solution: wrapping an "eval" around the call to Execute, like this:

## Locate and pre-compile any EPL files in the "live" directories of
## any of the sites.

use File::Find;
my @EPLFiles;
sub FindEPLFiles
{
    if (/\.AppleDouble/) {$File::Find::prune = 1; return};
    if (/\.epl$/) {push @EPLFiles, $File::Find::name;}
}

&find(\&FindEPLFiles, glob ('/sites/*/live/'));

foreach (@EPLFiles)
{
    my $Ignored;
    eval
    {
    &HTML::Embperl::Execute
        ({
            output =>     \$Ignored,
            inputfile =>  $_,
            virtlog =>    $ENV{EMBPERL_VIRTLOG},
            debug =>      $EmbPerlDebugOpts,
            options =>    $EmbPerlOptions,
        });
    }
}

==> Question: will putting an eval around the call to Execute mitigate the problems caused by the unwanted failures to run, while still having the desired effect of pre-compiling those that run correctly?  Also: for those that compile OK but refuse to run, will their compiled code still be retained by EmbPerl and shared by child processes? 

==> Another proposed solution:  calling "import" mode of Execute.  Would calling Execute in "import" mode have the same code-caching benefits without actually trying to run the code on the page at server startup time?  If so, this would seem to be the best solution of all. 

==> Would there be an advantage to combining the "eval" and "import" approaches to protect against pages with Embperl syntax errors clogging the server startup process?

-c



-chris

------------------------------------------------------------------------
870 Market Street #1270                           (415) 394-9818
San Francisco, CA 94102                           (413) 473-0853 fax
------------------------------------------------------------------------

RE: Pre-compiling Embperl pages without Executing?

Posted by Gerald Richter <ri...@ecos.de>.
> ==> Question: will putting an eval around the call to Execute 
> mitigate the problems caused by the unwanted failures to run, 
> while still having the desired effect of pre-compiling those that 
> run correctly?  

Yes

> Also: for those that compile OK but refuse to 
> run, will their compiled code still be retained by EmbPerl and 
> shared by child processes? 
> 

Yes

> ==> Another proposed solution:  calling "import" mode of Execute. 
>  Would calling Execute in "import" mode have the same 
> code-caching benefits without actually trying to run the code on 
> the page at server startup time? 

No. It will only precompile the code between [$sub $] and [$ endsub $]

> 
> ==> Would there be an advantage to combining the "eval" and 
> "import" approaches to protect against pages with Embperl syntax 
> errors clogging the server startup process?
> 

I think, currently the eval method is the best one. 

Gerald

-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925151
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------