modperl_tracking_down_why_a_module_was_loaded

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: tracking down why a module was loaded?;
From: Justin <jb@dslreports.com>
Date: Thu, 14 Sep 2000 16:19:00 -0400

Can anyone tell me the easiest slickest way of determining
what was responsible for requesting a module, having discovered
that it has been loaded when viewing perl-status?


and while I've got the podium:
I would like to congratulate Doug and 
everyone involved in modperl.. by checking
pcdataonline.com, I found our entirely modperl site is
now #1850 in the top 10,000 websites, with over 10 million
*entirely dynamic* pages pushed out a month.. to half a 
million unique users. This is a single Dell 2300 box with
two PII 450s cpus and a gig of memory.. (the mysql server
is on another box). Most pages are built between 20-100ms
of user time.. the same box runs backend and frontend
servers, serves images as well, plus a hunk of other
processes.
If a fortune500 company asked razor fish / concrete media
to build them a website that would scale to that, with
entirely dynamic pages, they'd be dragging the client down
to Sun to pick out the color of their enterprise 4000, or
microsoft would be pushing a cluster of multi processor
compaqs and NT servers with all possible software trimmings
added.. and then you'd need a team of specialists to keep
the whole thing moving.. no wonder dotcoms go broke.

modperl is the best kept secret on the net. Shame!

===

Subject: Re: tracking down why a module was loaded?;
From: Stas Bekman <stas@stason.org>
Date: Thu, 14 Sep 2000 22:46:39 +0200 (CEST)

On Thu, 14 Sep 2000, Justin wrote:

> Can anyone tell me the easiest slickest way of determining
> what was responsible for requesting a module, having discovered
> that it has been loaded when viewing perl-status?

A.pm:
 -----
package A;
use Carp ();
BEGIN { Carp::cluck("I don't want to wake up!!!")}
1;

test.pl
 -------
require "A.pm";

now run:
% perl test.pl
I don't want to wake up!!! at A.pm line 4
	A::BEGIN() called at A.pm line 4
	eval {...} called at A.pm line 4
	require A.pm called at test.pl line 1

Also see:
perldoc -f caller

===

Subject: Re: tracking down why a module was loaded?;
From: Matt Sergeant <matt@sergeant.org>
Date: Fri, 15 Sep 2000 00:27:03 +0100 (BST)

On Thu, 14 Sep 2000, Justin wrote:

> Can anyone tell me the easiest slickest way of determining
> what was responsible for requesting a module, having discovered
> that it has been loaded when viewing perl-status?

use OtherPackage; # because you need import to be defined first
sub OtherPackage::import {
 warn join(':', caller), " tried to load me\n";
}

Not foolproof, and could cause more damage than good, but sometimes its a
useful debugging technique.

> modperl is the best kept secret on the net. Shame!

Indeed!

===

Subject: Re: tracking down why a module was loaded?
From: Justin <jb@dslreports.com>
Date: Fri, 15 Sep 2000 03:22:46 -0400

Thanks for the hint. It worked perfectly. I didnt connect
Cluck, and BEGIN. doh.

nobody spotted the unintended irony in my question ..
perl-status itself (Apache::Status) was the one pulling in CGI.pm !!

Turns out, if you load Apache::Request before Apache::Status,
it uses that instead of the (large) CGI.pm .. that wasnt mentioned
in my Apache::Status manual :-(

===

Subject: Re: tracking down why a module was loaded?;
From: Stas Bekman <stas@stason.org>
Date: Fri, 15 Sep 2000 15:07:01 +0200 (CEST)

On Fri, 15 Sep 2000, Matt Sergeant wrote:

> On Thu, 14 Sep 2000, Justin wrote:
> 
> > Can anyone tell me the easiest slickest way of determining
> > what was responsible for requesting a module, having discovered
> > that it has been loaded when viewing perl-status?
> 
> use OtherPackage; # because you need import to be defined first
> sub OtherPackage::import {
>  warn join(':', caller), " tried to load me\n";
> }

Not really. import() is not called for any of these. 
use Foo ();
require Foo;
do Foo;

BEGIN{}+cluck in the code or just cluck will do per my original reply.

===

Subject: Re: tracking down why a module was loaded?;
From: Matt Sergeant <matt@sergeant.org>
Date: Fri, 15 Sep 2000 14:20:57 +0100 (BST)

On Fri, 15 Sep 2000, Stas Bekman wrote:

> On Fri, 15 Sep 2000, Matt Sergeant wrote:
> 
> > On Thu, 14 Sep 2000, Justin wrote:
> > 
> > > Can anyone tell me the easiest slickest way of determining
> > > what was responsible for requesting a module, having discovered
> > > that it has been loaded when viewing perl-status?
> > 
> > use OtherPackage; # because you need import to be defined first
> > sub OtherPackage::import {
> >  warn join(':', caller), " tried to load me\n";
> > }
> 
> Not really. import() is not called for any of these. 
> use Foo ();
> require Foo;
> do Foo;
> 
> BEGIN{}+cluck in the code or just cluck will do per my original reply.

Yep, its a better solution in most cases, except you have to edit the
original package for it to work. Sometimes thats not possible (e.g. on a
system you don't have admin rights for). So two solutions to the problem
are simply good to know.

===

Subject: Re: tracking down why a module was loaded?;
From: Doug MacEachern <dougm@covalent.net>
Date: Mon, 25 Sep 2000 13:03:22 -0700 (PDT)

On Thu, 14 Sep 2000, Justin wrote:

> Can anyone tell me the easiest slickest way of determining
> what was responsible for requesting a module, having discovered
> that it has been loaded when viewing perl-status?

override the builtin require with CORE::GLOBAL::require.  something like
the below prints a stacktrace to tell you where the require is called
from.  the two eval's are used to handle both "Foo.pm" and the bareword
form of 'use Foo'.

use Carp ();

BEGIN {
    sub My::require {
        my $thing = shift;
        Carp::cluck($thing);
        eval {
            CORE::require($thing);
        } or eval "CORE::require($thing)";
        die $@ if $@;
    }
    *CORE::GLOBAL::require = \&My::require;
}

sub blah {
    require Foo;
}

blah();
 
> and while I've got the podium:
> I would like to congratulate Doug and 
> everyone involved in modperl.. by checking
> pcdataonline.com, I found our entirely modperl site is
> now #1850 in the top 10,000 websites, with over 10 million
> *entirely dynamic* pages pushed out a month.. to half a 
> million unique users. This is a single Dell 2300 box with
> two PII 450s cpus and a gig of memory.. (the mysql server
> is on another box). Most pages are built between 20-100ms
> of user time.. the same box runs backend and frontend
> servers, serves images as well, plus a hunk of other
> processes.

great to hear, thanks for sharing that.
 
> modperl is the best kept secret on the net. Shame!

seems to generate plenty of list traffic for a "secret" ;)

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu