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
-------------------------------------------------------------