Re: Apache::Perfmon 0.011

[Stas Bekman]

On Thu, 24 Aug 2000, Lupe Christoph wrote:

> Hello!
> 
> Sorry about the lack of response. I was very busy the last few days.
> 
> On Tuesday, 2000-08-22 at 11:26:00 +0200, Stas Bekman wrote:
> > On Tue, 22 Aug 2000, Lupe Christoph wrote:
> 
> > > I thought about it a little more. What is does is find the
> > > (cpu|real)time taken to process a request. So what about
> > > Apache::RequestTimer or maybe Apache::Perf::RequestTimer, creating
> > > a new namespace for all performance-related modules?
> 
> > Both sound good time, especially the second :)
> 
> Apache::Perf::RequestTimer it is. then. The next version will
> carry the new name (whatever it does ;-).

Ok. So we are about to open a new tree Apache::Perf. Good. 

> > > This times the entire request. I'll split the CPU times out in times
> > > for the Apache process and that for it and all it's children in the
> > > nect release to accomodate CGI. Can't do anything about FastCGI
> > > and such things that run independent of the Apache process.
> 
> > If you are going to make it non-mod_perl specific (if I understand your
> > intentions correctly) you shouldn't put it under Apache:: tree.
> 
> Nope. I'll stick to mod_perl. But it is not mod_perl-specific in
> what it measures.  You can use it to measure PHP and mod_.
> It just uses mod_perl. FastCGI and kin use external processes,
> for which this approach can't gather CPU statistics.

Great! I didn't think about this. It'd be really cool, if php users will
plug mod_perl in especially for performance measuring :)

> > > As for statistics, I'm thinking about splitting out the host
> > > first, second the method (GET, POST, etc), then the URI, with the
> > > request string removed, maybe the request strings under the URI
> > > at a later time.
> 
> > A good advise would be to let the user to specify the format, following
> > for example the same format that one uses to specify log format in Apache,
> > may be with extra tokens, which are unavailable by Apache.
> 
> I thought about this, too. It's a little much for a first shot,
> unless somebody has code I can borrow. And then, this might be
> a nice module in itself...

Ok

> > BTW, the time taken to server the request is already there: %...{format}t:
> 
> Have you tried that? It gives you entire seconds! That's why I started
> on this module in the first place.

Nope, I didn't. Wrong suggestion, sorry.

> > > Print the top  requests by user CPU, system CPU, realtime.
> > > Do that in plain text and HTML, with graphs later.
> 
> > BTW, Apache::VMonitor does that this in the real time, for the last
> > request.
> 
> I'll have a look at that. maybe there's code waiting to be stolen...

may be :)

_
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

Re: Apache::Perfmon 0.011

[Lupe Christoph]

On Wednesday, 2000-08-23 at 12:32:58 +0200, Stas Bekman wrote:
> On Wed, 23 Aug 2000, Ask Bjoern Hansen wrote:

> > On Tue, 22 Aug 2000, Stas Bekman wrote:

> > [...]
> > > Sorry, it's in contrib, not the book:
> > > http://perl.apache.org/dist/contrib/Timeit.pm

> > And I have an improved version which I for some reason never
> > uploaded to CPAN. I guess I didn't get everything I wanted to work
> > to work. :) Next time I need it I'll probably finish it and upload
> > it. (it was one of the few remaining useful bits of contrib).

> So may be it would be a cool idea for you Ask and Lupe to put your code
> together and have one module instead two doing a very similar thing. Just
> an attempt to keep the available modules choice non-ambiguous of course,
> feel free to do whatever you feel is right of course.

I'll have a look at the contrib this weekend.

Ask, if you want me to look if we *can* collapse you stuff and mine,
please mail your modified version to me.

Lupe
-- 
| [EMAIL PROTECTED]   |http://free.prohosting.com/~lupe |
| "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur |
| qbbzfnlref unir orra cebira jebat lrg ntnva."    "qvq lbh frr gung |
| gbb?" "ubhfgba. jr unir n ceboyrz."   User Friendly 2000-01-01 |

Re: Apache::Perfmon 0.011

[Lupe Christoph]

Hello!

Sorry about the lack of response. I was very busy the last few days.

On Tuesday, 2000-08-22 at 11:26:00 +0200, Stas Bekman wrote:
> On Tue, 22 Aug 2000, Lupe Christoph wrote:

> > I thought about it a little more. What is does is find the
> > (cpu|real)time taken to process a request. So what about
> > Apache::RequestTimer or maybe Apache::Perf::RequestTimer, creating
> > a new namespace for all performance-related modules?

> Both sound good time, especially the second :)

Apache::Perf::RequestTimer it is. then. The next version will
carry the new name (whatever it does ;-).

> > I'll include a first shot at such a program in the next release.
> > After the naming discussion has settled down.

Seems I'm committed ;-)

> > This times the entire request. I'll split the CPU times out in times
> > for the Apache process and that for it and all it's children in the
> > nect release to accomodate CGI. Can't do anything about FastCGI
> > and such things that run independent of the Apache process.

> If you are going to make it non-mod_perl specific (if I understand your
> intentions correctly) you shouldn't put it under Apache:: tree.

Nope. I'll stick to mod_perl. But it is not mod_perl-specific in
what it measures.  You can use it to measure PHP and mod_.
It just uses mod_perl. FastCGI and kin use external processes,
for which this approach can't gather CPU statistics.

> > Is anybody running Apache+mod_perl under Win32 who could see if
> > times() and Time::HiRes give you timings of any significance
> > on that platform?

Hmm, no response to this. I'll usethe skeet shooting approach.
Launch and see if it gets shot down.

> > As for statistics, I'm thinking about splitting out the host
> > first, second the method (GET, POST, etc), then the URI, with the
> > request string removed, maybe the request strings under the URI
> > at a later time.

> A good advise would be to let the user to specify the format, following
> for example the same format that one uses to specify log format in Apache,
> may be with extra tokens, which are unavailable by Apache.

I thought about this, too. It's a little much for a first shot,
unless somebody has code I can borrow. And then, this might be
a nice module in itself...

> BTW, the time taken to server the request is already there: %...{format}t:

Have you tried that? It gives you entire seconds! That's why I started
on this module in the first place.

> > Print the top  requests by user CPU, system CPU, realtime.
> > Do that in plain text and HTML, with graphs later.

> BTW, Apache::VMonitor does that this in the real time, for the last
> request.

I'll have a look at that. maybe there's code waiting to be stolen...

-- 
| [EMAIL PROTECTED]   |http://free.prohosting.com/~lupe |
| "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur |
| qbbzfnlref unir orra cebira jebat lrg ntnva."    "qvq lbh frr gung |
| gbb?" "ubhfgba. jr unir n ceboyrz."   User Friendly 2000-01-01 |

Re: Apache::Perfmon 0.011

[Stas Bekman]

On Wed, 23 Aug 2000, Ask Bjoern Hansen wrote:

> On Tue, 22 Aug 2000, Stas Bekman wrote:
> 
> [...]
> > Sorry, it's in contrib, not the book:
> > http://perl.apache.org/dist/contrib/Timeit.pm
> 
> And I have an improved version which I for some reason never
> uploaded to CPAN. I guess I didn't get everything I wanted to work
> to work. :) Next time I need it I'll probably finish it and upload
> it. (it was one of the few remaining useful bits of contrib).

So may be it would be a cool idea for you Ask and Lupe to put your code
together and have one module instead two doing a very similar thing. Just
an attempt to keep the available modules choice non-ambiguous of course,
feel free to do whatever you feel is right of course.


_
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

Re: Apache::Perfmon 0.011

[Ask Bjoern Hansen]

On Tue, 22 Aug 2000, Stas Bekman wrote:

[...]
> Sorry, it's in contrib, not the book:
> http://perl.apache.org/dist/contrib/Timeit.pm

And I have an improved version which I for some reason never
uploaded to CPAN. I guess I didn't get everything I wanted to work
to work. :) Next time I need it I'll probably finish it and upload
it. (it was one of the few remaining useful bits of contrib).
 


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Apache::Perfmon 0.011

[George Sanderson]

At 11:26 AM 8/22/00 +0200, you wrote:
>On Tue, 22 Aug 2000, Lupe Christoph wrote:
>
>> On Monday, 2000-08-21 at 21:06:54 -0400, Greg Stark wrote:
>> 
>> > Lupe Christoph <[EMAIL PROTECTED]> writes:
>> 
>> > > Hmm. Apache::Benchmark sounds more like a benchmark driver to me.
>> > > Apache::Instrumentation or so? Apache::Probe?
>> 
>> > Profile or even just Prof.
>
>That would be misleading. A profiler is something much more sophisticated
>and provides you a lot of information about the code that gets
>executed. More over the Apache::DProf and Apache::SmallProf are already in
>place.
>
>> I thought about it a little more. What is does is find the
>> (cpu|real)time taken to process a request. So what about
>> Apache::RequestTimer or maybe Apache::Perf::RequestTimer, creating
>> a new namespace for all performance-related modules?
>
>Both sound good time, especially the second :)

How about a take off from vmstat (a great UNIX tool) and call it
Apache::HTStat

Re: Apache::Perfmon 0.011

[Stas Bekman]

On Tue, 22 Aug 2000, Lupe Christoph wrote:

> On Monday, 2000-08-21 at 21:06:54 -0400, Greg Stark wrote:
> 
> > Lupe Christoph <[EMAIL PROTECTED]> writes:
> 
> > > Hmm. Apache::Benchmark sounds more like a benchmark driver to me.
> > > Apache::Instrumentation or so? Apache::Probe?
> 
> > Profile or even just Prof.

That would be misleading. A profiler is something much more sophisticated
and provides you a lot of information about the code that gets
executed. More over the Apache::DProf and Apache::SmallProf are already in
place.

> I thought about it a little more. What is does is find the
> (cpu|real)time taken to process a request. So what about
> Apache::RequestTimer or maybe Apache::Perf::RequestTimer, creating
> a new namespace for all performance-related modules?

Both sound good time, especially the second :)

> > What I think it needs is, a way to gather the statistics in a hash based on
> > the request. That way I can make a web page that pokes around in the hash
> > table and reports the average and maximum time taken by page.
> 
> I'd rather not collect the statistics inside the module. Not only can
> that inflate the process, it's also much better done seperately
> because this way you can write your own statistics processor without
> touching the gatherer.

true.

> I'll include a first shot at such a program in the next release.
> After the naming discussion has settled down.
> 
> > I'm not clear how or if that can be done in a separate module like this that
> > doesn't know how the requests are dispatched. Either a regexp needs to be
> > provided that returns the key to use for the hash, or else something similar
> > needs to be integrated into packages like CGI and Apache::ASP. (Which was the
> > approach I was planning on taking myself.) I like this approach better though,
> > so it would be neat to see it polished.
> 
> This times the entire request. I'll split the CPU times out in times
> for the Apache process and that for it and all it's children in the
> nect release to accomodate CGI. Can't do anything about FastCGI
> and such things that run independent of the Apache process.

If you are going to make it non-mod_perl specific (if I understand your
intentions correctly) you shouldn't put it under Apache:: tree.

> Is anybody running Apache+mod_perl under Win32 who could see if
> times() and Time::HiRes give you timings of any significance
> on that platform?
> 
> As for statistics, I'm thinking about splitting out the host
> first, second the method (GET, POST, etc), then the URI, with the
> request string removed, maybe the request strings under the URI
> at a later time.

A good advise would be to let the user to specify the format, following
for example the same format that one uses to specify log format in Apache,
may be with extra tokens, which are unavailable by Apache.

http://www.apache.org/docs/mod/mod_log_config.html

BTW, the time taken to server the request is already there: %...{format}t:

> Print the top  requests by user CPU, system CPU, realtime.
> Do that in plain text and HTML, with graphs later.

BTW, Apache::VMonitor does that this in the real time, for the last
request.

_
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

Re: Apache::Perfmon 0.011

[Stas Bekman]

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 as Apache::Auth:: 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

Re: Apache::Perfmon 0.011

[Lupe Christoph]

On Monday, 2000-08-21 at 21:06:54 -0400, Greg Stark wrote:

> Lupe Christoph <[EMAIL PROTECTED]> writes:

> > Hmm. Apache::Benchmark sounds more like a benchmark driver to me.
> > Apache::Instrumentation or so? Apache::Probe?

> Profile or even just Prof.

I thought about it a little more. What is does is find the
(cpu|real)time taken to process a request. So what about
Apache::RequestTimer or maybe Apache::Perf::RequestTimer, creating
a new namespace for all performance-related modules?

> I looked at this and really like the idea. Unfortunately I need to recompile
> my Apache to use it.

Yeah, it inserts handlers in phases few modules touch. I should
mention that in my README.

> What I think it needs is, a way to gather the statistics in a hash based on
> the request. That way I can make a web page that pokes around in the hash
> table and reports the average and maximum time taken by page.

I'd rather not collect the statistics inside the module. Not only can
that inflate the process, it's also much better done seperately
because this way you can write your own statistics processor without
touching the gatherer.

I'll include a first shot at such a program in the next release.
After the naming discussion has settled down.

> I'm not clear how or if that can be done in a separate module like this that
> doesn't know how the requests are dispatched. Either a regexp needs to be
> provided that returns the key to use for the hash, or else something similar
> needs to be integrated into packages like CGI and Apache::ASP. (Which was the
> approach I was planning on taking myself.) I like this approach better though,
> so it would be neat to see it polished.

This times the entire request. I'll split the CPU times out in times
for the Apache process and that for it and all it's children in the
nect release to accomodate CGI. Can't do anything about FastCGI
and such things that run independent of the Apache process.

Is anybody running Apache+mod_perl under Win32 who could see if
times() and Time::HiRes give you timings of any significance
on that platform?

As for statistics, I'm thinking about splitting out the host
first, second the method (GET, POST, etc), then the URI, with the
request string removed, maybe the request strings under the URI
at a later time.

Print the top  requests by user CPU, system CPU, realtime.
Do that in plain text and HTML, with graphs later.

Lupe
-- 
| [EMAIL PROTECTED]   |http://free.prohosting.com/~lupe |
| "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur |
| qbbzfnlref unir orra cebira jebat lrg ntnva."    "qvq lbh frr gung |
| gbb?" "ubhfgba. jr unir n ceboyrz."   User Friendly 2000-01-01 |

Re: Apache::Perfmon 0.011

[Greg Stark]

Lupe Christoph <[EMAIL PROTECTED]> writes:

> Hmm. Apache::Benchmark sounds more like a benchmark driver to me.
> Apache::Instrumentation or so? Apache::Probe?

Profile or even just Prof.

I looked at this and really like the idea. Unfortunately I need to recompile
my Apache to use it.

What I think it needs is, a way to gather the statistics in a hash based on
the request. That way I can make a web page that pokes around in the hash
table and reports the average and maximum time taken by page.

I'm not clear how or if that can be done in a separate module like this that
doesn't know how the requests are dispatched. Either a regexp needs to be
provided that returns the key to use for the hash, or else something similar
needs to be integrated into packages like CGI and Apache::ASP. (Which was the
approach I was planning on taking myself.) I like this approach better though,
so it would be neat to see it polished.

-- 
greg

Re: Apache::Perfmon 0.011

[Lupe Christoph]

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.

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

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

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

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

BTW, I forgot to put in a PREREQ_PM and a paragraph in the Requirements
section of the README mentioning Time::HiRes.

> 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 as Apache::Auth:: for some time...

Another shot at a good name: Apache::Probe::Simple? Leaving room
for Apache::Probe::Sophisticated. ;-)

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

Lupe
-- 
| [EMAIL PROTECTED]   |http://free.prohosting.com/~lupe |
| "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur |
| qbbzfnlref unir orra cebira jebat lrg ntnva."    "qvq lbh frr gung |
| gbb?" "ubhfgba. jr unir n ceboyrz."   User Friendly 2000-01-01 |

Re: Apache::Perfmon 0.011

[Stas Bekman]

On Mon, 21 Aug 2000, Lupe Christoph wrote:

> On Sunday, 2000-08-20 at 23:45:55 +0200, Stas Bekman wrote:
> 
> > Lupe,
> > It seems to be broken. I cannot open the package.
> 
> I've uploaded it again, and will be testing it myself.
> 
> To be sure you get it, I'm attaching the tarball, it's minor, anyway.

Thanks, Lupe.

A few comments followed by the answer to your original question.

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:

Installing /usr/lib/perl5/site_perl/5.005/Apache/Perfmon.pm
Installing /usr/lib/perl5/man/man3/Apache::Perfmon.3

   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.

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

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.

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

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.


_
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

Apache::Perfmon 0.011

[Lupe Christoph]

Thanks to Balazs Rauznitz <[EMAIL PROTECTED]> for pointing
out an embarrasing thinko. The corrected version is at

http://free.prohosting.com/~lupe/Personal/Perl/Apache-Perfmon/Apache-Perfmon-0.011.tar.gz

Sorry if you already grabbed this.
Lupe Christoph
-- 
| [EMAIL PROTECTED]   |http://free.prohosting.com/~lupe |
| "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur |
| qbbzfnlref unir orra cebira jebat lrg ntnva."    "qvq lbh frr gung |
| gbb?" "ubhfgba. jr unir n ceboyrz."   User Friendly 2000-01-01 |