On Mon, 21 Aug 2000, Lupe Christoph wrote:
> On Monday, 2000-08-21 at 10:41:51 +0200, Stas Bekman wrote:
> > On Mon, 21 Aug 2000, Lupe Christoph wrote:
>
> > A few comments followed by the answer to your original question.
>
> Thanks!
>
> > make install
> > Manifying blib/man3/Apache::Changes.3
> > Manifying blib/man3/Apache::Perfmon.3
> > Manifying blib/man3/Apache::README.3
> > Installing /usr/lib/perl5/site_perl/5.005/Apache/Perfmon.pm
> > Installing /usr/lib/perl5/site_perl/5.005/Apache/Changes.pod
> > Installing /usr/lib/perl5/site_perl/5.005/Apache/README.pod
> > Installing /usr/lib/perl5/man/man3/Apache::Changes.3
> > Installing /usr/lib/perl5/man/man3/Apache::Perfmon.3
> > Installing /usr/lib/perl5/man/man3/Apache::README.3
>
> > All these:
> > Installing /usr/lib/perl5/site_perl/5.005/Apache/Changes.pod
> > Installing /usr/lib/perl5/site_perl/5.005/Apache/README.pod
> > Installing /usr/lib/perl5/man/man3/Apache::Changes.3
> > Installing /usr/lib/perl5/man/man3/Apache::README.3
>
> > shoudn't happen. It misleads since you install Apache/Changes.pod and
> > Apache/README.pod which can be interpeted as mod_perl base files. And of
> > course there is no need to install these system wide. All you want is:
>
> Blush. I didn't even use make install... I'll have to check
> how to suppress the installation of the PODs. Maybe I'll just
> leave them out of the dist and include Changes/README and
> their HTML versions.
Just look at how any other packages are written and you will solve this
issue easily. Of course you can look at ExtUtil::MakeMaker manpage
instead.
> > The logfile is opened only once for each apache
> > subprocess. This is done to reduce the overhead caused by
> > this module, but it also means that logfile rotation can
> > be painful.
>
> > Why don't you open it at the server startup (when you preload
> > Apache::Perfmon) and all the children will inherit the opened FH.
>
> Meanwhile I thought about the situation where you have several virtual
> hosts, and want separate logging for each. I'll have to use a hash
> by the server name. I'll put that in later this week.
ok
> > Now the name -- it should be different. You've picked a name which is too
> > generic, while it explores only one side of performance measuring. Doug
> > has already a module called Apache::TimeIt from his book, whose idea is
> > more or less the same. It was presented as an example and therefore has
> > almost no code in it :)
>
> Mine has little more if any at all. :-)
> I can't find Apache::TimeIt with a cursory look in the book,
> so I'll have to browse some more when I have the time.
Sorry, it's in contrib, not the book:
http://perl.apache.org/dist/contrib/Timeit.pm
> > Since I work my self on Apache::Benchmark module, I'm thinking about
> > putting all the performance monitoring and benchmarking modules under the
> > same roof. Apache::Benchmark sounds like a good choice to me.
>
> Hmm. Apache::Benchmark sounds more like a benchmark driver to me.
> Apache::Instrumentation or so? Apache::Probe?
Yeah, it's true. How about Apache::Log::RunTime and Apache::Log::RunCPU --
since all it does is samling and loggind the data.
> > Therefore I would suggest calling your module Apache::Benchmark::CPU and
> > Apache::Benchmark::Handler (hmm, I think that it can be a good idea to
> > have these two functions separated, therefore I've suggested these two
> > different modules).
>
> Sorry, I can't see where you want to divide this. The module has
> two probes (I'm beginning to like that word), and little more.
> Of course you could divide it in a realtime and a CPU probe...
Yup, that's exactly my point. Of course you can have a single module with
a few functions, so one can choose either or both. Like Apache::ExecLog...
> > I know that people aren't favorite of modules whose names are of more than
> > 2 levels deepnees, but in order to insure a healthy ground for the future
> > emerging modules, this "sacrificing" is a due.
>
> I'm not opposed to this at all. Actually I've been thinking about
> Apache::Auth<foo> as Apache::Auth::<foo> for some time...
>
> Another shot at a good name: Apache::Probe::Simple? Leaving room
> for Apache::Probe::Sophisticated. ;-)
It's not clear from the name what the module does. The name you suggest is
too generic, while the module does very specific things.
> I haven't registered this module with CPAN mainly because I was unsure
> of the appropriate name myself, and because I wasn't sure if somebody
> hadn't already written Apache::Probe::Sophisticated...
Absolutely good!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
