Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

startup.pl mod_perl question

Quote Reply
startup.pl mod_perl question
Is this fine for PerlRequire /path/to/startup.pl in mod_perl or should we add or remove something?

#!/usr/bin/perl

$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die "GATEWAY_INTERFACE not Perl!";

BEGIN {
unshift(@INC, "/path /to//admin");
}

use Apache::DBI;
use Links;
use Links::DBSQL;
use Links::DB_Utils;
use Links::HTML_Templates;
Apache::DBI->connect_on_init("DBI:mysql:database:localhost", "user", "password");
Apache::DBI->{'Warn'} = 0;
1;

Thank you.

Quote Reply
Re: startup.pl mod_perl question In reply to
This is probably something Alex should answer, since there really isn't enough experience on this.

I'm not sure what modules need to be loaded in the startup.pl file.

As it is, the program runs under mod_perl, but I've had questions about performance and resource gains loading them in the start up script.

If you were running under mod_perl, the initial installation includes setup, and Alex or one of his people should have done that for you. that is why (most likely) there is no real documentation on it. They do it for you.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: startup.pl mod_perl question In reply to
Thanks pugdog.
If Alex reads this... can you put up the source of what startup.pl should be?
thanks.

Quote Reply
Re: startup.pl mod_perl question In reply to
Hi!

That's fine. The only additions I would suggest are:

use CGI qw/-compile :all/;

which will preload the CGI modules with all methods compiled.

Also, if you want even better performance, investigate Apache::RegistryLoader which will precompile all your .cgi scripts as well. This can be useful as it can reduce memory usage, but in terms of performance, it doesn't offer too much as the script is only compiled once per new httpd child (they should stay around for thousands of requests).

Hope that helps,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: startup.pl mod_perl question In reply to
>> httpd child (they should stay around for thousands of requests).

That's not a very good thing.... usually the idea is to let a child handle about 100-150 requests then exit, and be reinitialized. I know certain Solaris libraries had memory leaks, other OS's and user scripts unless very carefully debugged would ineveitably have some leaks, so reclaiming the child process after a reasonable number of requests is sort of the standard plan.

Here's the default setting and comments from the apache httpd.conf:

Code:
#
# MaxRequestsPerChild: the number of requests each child process is
# allowed to process before the child dies. The child will exit so
# as to avoid problems after prolonged use when Apache (and maybe the
# libraries it uses) leak memory or other resources. On most systems, this
# isn't really needed, but a few (such as Solaris) do have notable leaks
# in the libraries.
#
MaxRequestsPerChild 30

I'm not sure how using mod_perl would change that, but somehow, "thousands" of requests per child made the hair on the back of my neck stand up.

Am I showing my age again??

(BTW.... the closing pre tag is still stripping blank lines up to the start of the first non-blank one. I had 3 blank lines, and as you can see, the first non-blank line is still being forced against the closing pre-tag


http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: startup.pl mod_perl question In reply to
Ack, no. Apache and o/s's have come a long way since then, and you should really have your value quite a bit higher (couple thousand or even 0). Our main front-end web server is set to 0, and has an uptime of a couple of weeks. Perl scripts don't cause memory leaks in the main code as perl is destroyed every request.

With mod_perl there are other things to consider:

- too low a maxrequests and you negate any benefit of having mod_perl as you need to spawn a new child, load perl, load scripts, quite often.
- too high a maxrequests and you need to make _very_ sure your perl code doesn't have any memory leaks in it. Something as simple as:

push @GLOBAL, "something";

would cause an ever growing array in mod_perl (as the variable never gets destroyed properly). These sort of errors need to be fixed, but other more subtle ones you can live with by setting a not too high maxrequests.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: startup.pl mod_perl question In reply to
Oh, also, avoid:

BEGIN {
unshift(@INC, "/path /to//admin");
}

but rather:

use lib '/full/path/to/admin';

instead. If you use unshift @INC's inside code (not in begin blocks) you can grow INC indefinately.

Cheers,

Alex

--
Gossamer Threads Inc.