Re: PerlRun Gotchas?
[My apologies for two copies of my original message turning up. My bad.] In article 00a901c1a44d$7d087d70$18020c0a@PerriHar, Perrin Harkins [EMAIL PROTECTED] wrote: I would not expect PerlRun to use less memory than Registry. What I meant was that I have about a dozen of these little scripts. My understanding is that PerlRun uses the embedded Perl interpreter, but compiles and executes the scripts individually on each request, whereas Registry caches the compiled version, potentially meaning a dozen compiled versions cached for each of a bunch of processes. I figured using PerlRun would avoid that, but provide a useful intermediate performance boost by not forking perl each time. Have I misunderstood? Does the module have a package name? Are you exporting the variables from it? Seeing some code would help. It does, and what confuses me is the intermittent nature of the problem. Anyway, here's some code (snipped wildly into a minimal test case, and with the paths replaced): The module: #!/usr/bin/perl package Article7::Woking::Overseer; use strict; require Exporter; use vars qw(@ISA @EXPORT $root $dbmx); @ISA = qw(Exporter); @EXPORT = qw($dbmx); $dbmx = 'path-to-data-files'; 1; ...and the PerlRun program: #!/usr/bin/perl use strict; use CGI qw(:standard); use Fcntl; use MLDBM qw(DB_File Storable); use lib 'path-to-directory'; use Article7::Woking::Overseer; print header(-type = 'text/html; charset=utf-8'); tie(my %accom, 'MLDBM', $dbmx/accom.dbmx, O_RDONLY, 0644) or die Can't open $dbmx/accom.dbmx: $!\n; [...] The error log reveals that it's this tie that kills the program -- $dbmx remains undef, so the file isn't found. 200 OK That just means the error happened after the initial header was sent. Ah, I see. Yes, of course -- the first thing I do is send the header! Thanks for the ref to the Guide -- I've looked through that section again now, but I think I must be still missing something. I'm afraid running in single-server mode would be troublesome, as the server is in production use for other sites. Many thanks for your help, Andrew. -- Mind you, you'd expect that of cows, wouldn't you? Two stomachs, know what I mean?-- Liza Tarbuck
Re: PerlRun Gotchas?
Andrew Green wrote: [My apologies for two copies of my original message turning up. My bad.] In article 00a901c1a44d$7d087d70$18020c0a@PerriHar, Perrin Harkins [EMAIL PROTECTED] wrote: I would not expect PerlRun to use less memory than Registry. What I meant was that I have about a dozen of these little scripts. My understanding is that PerlRun uses the embedded Perl interpreter, but compiles and executes the scripts individually on each request, whereas Registry caches the compiled version, potentially meaning a dozen compiled versions cached for each of a bunch of processes. I figured using PerlRun would avoid that, but provide a useful intermediate performance boost by not forking perl each time. Have I misunderstood? Yes and No, PerlRun flushes the namespace of the script, and Perl will reuse the memory freed by this flush, but it won't shrink the process, since the memory is never given back to the system till the process quits. So I you do save some memory, but not all of it. Check with the Apache::Status module which will show you exactly how much you save. See the notes in the guide and the manpage. But you miss an important point. If you use PerlRun, you add an overhead of compilation of your scripts. If you were using Registry your response will be faster = you need less servers to serve the same load, = you need less memory overall. Again I cannot tell you absolutely that it's true for all cases, you have to measure it yourself. The guide's performance chapter provides a plenty of examples on how to approach the problems. Also read about memory sharing and preloading in the same chapter http://perl.apache.org/guide/performance.html Does the module have a package name? Are you exporting the variables from it? Seeing some code would help. It does, and what confuses me is the intermittent nature of the problem. Anyway, here's some code (snipped wildly into a minimal test case, and with the paths replaced): The module: #!/usr/bin/perl package Article7::Woking::Overseer; use strict; require Exporter; use vars qw(@ISA @EXPORT $root $dbmx); @ISA = qw(Exporter); @EXPORT = qw($dbmx); $dbmx = 'path-to-data-files'; 1; ...and the PerlRun program: #!/usr/bin/perl use strict; use CGI qw(:standard); use Fcntl; use MLDBM qw(DB_File Storable); use lib 'path-to-directory'; use Article7::Woking::Overseer; print header(-type = 'text/html; charset=utf-8'); tie(my %accom, 'MLDBM', $dbmx/accom.dbmx, O_RDONLY, 0644) or die Can't open $dbmx/accom.dbmx: $!\n; [...] The error log reveals that it's this tie that kills the program -- $dbmx remains undef, so the file isn't found. I think your problem is that you don't declare the local variable when you import it. See: http://perl.apache.org/guide/perl.html#Using_Global_Variables_and_Shari and especially http://perl.apache.org/guide/perl.html#Using_Exporter_pm_to_Share_Globa -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
PerlRun Gotchas?
Hi, A site I run uses a fair variety of different programs, the most common of which are run through Apache::Registry. To cut the memory overhead, however, less commonly used programs are run through Apache::PerlRun. Both the Registry and PerlRun programs use a common module which defines a few subroutines and a selection of exported variables. These variables are in the module as globals (ie: no my declaration), but with a use vars to get them through strict. With seeming 50/50 frequency, the PerlRun programs work as intended, or alternatively return: 200 OK The server encountered an internal error or misconfiguration... ...More information about this error may be available in the server error log. Yes, it's not HTTP 500, it is 200. The error log indicates every time that this is due to a global set in my module that remains undef for the program that tries to call it (and an open that dies on failure requires the global). Hitting refresh normally does the trick. The moment I move from PerlRun to ordinary CGI, the problem vanishes. Equally, AFACT, it doesn't happen for Registry. I've searched the guide, but couldn't find anything of help. I have a use Apache::PerlRun (); in my startup file, the common module is also preloaded therein, and are also used in the PerlRun programs themselves. I'm running mod_perl 1.23 on Apache 1.3.19 (Red Hat). Any suggestions gratefully appreciated. Cheers, Andrew. -- Wow, that's almost as fun as meowing. -- http://www.exit109.com/%7Ejeremy/news/providers/4groups.html
Re: PerlRun Gotchas?
A site I run uses a fair variety of different programs, the most common of which are run through Apache::Registry. To cut the memory overhead, however, less commonly used programs are run through Apache::PerlRun. I would not expect PerlRun to use less memory than Registry. Both the Registry and PerlRun programs use a common module which defines a few subroutines and a selection of exported variables. These variables are in the module as globals (ie: no my declaration), but with a use vars to get them through strict. Does the module have a package name? Are you exporting the variables from it? Seeing some code would help. 200 OK The server encountered an internal error or misconfiguration... ...More information about this error may be available in the server error log. That just means the error happened after the initial header was sent. The error log indicates every time that this is due to a global set in my module that remains undef for the program that tries to call it (and an open that dies on failure requires the global). Again, some code would help. I suspect you are getting bitten by namespace collisions: http://perl.apache.org/guide/porting.html#Name_collisions_with_Modules_and - Perrin
PerlRun Gotchas?
Hi, A site I run uses a fair variety of different programs, the most common of which are run through Apache::Registry. To cut the memory overhead, however, less commonly used programs are run through Apache::PerlRun. Both the Registry and PerlRun programs use a common module which defines a few subroutines and a selection of exported variables. These variables are in the module as globals (ie: no my declaration), but with a use vars to get them through strict. With seeming 50/50 frequency, the PerlRun programs work as intended, or alternatively return: 200 OK The server encountered an internal error or misconfiguration... ...More information about this error may be available in the server error log. Yes, it's not HTTP 500, it is 200. The error log indicates every time that this is due to a global set in my module that remains undef for the program that tries to call it (and an open that dies on failure requires the global). Hitting refresh normally does the trick. The moment I move from PerlRun to ordinary CGI, the problem vanishes. Equally, it doesn't happen for Registry. I've searched the guide, but couldn't find anything of help. I have a use Apache::PerlRun (); in my startup file, the common module is also preloaded therein, and are also used in the PerlRun programs themselves. I'm running mod_perl 1.23 on Apache 1.3.19 (Red Hat). Any suggestions gratefully appreciated. Cheers, Andrew. -- Wow, that's almost as fun as meowing. -- http://www.exit109.com/%7Ejeremy/news/providers/4groups.html
