cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject Re: Making performance information available to docs
Date Tue, 23 May 2000 13:58:05 GMT
On Tue, May 23, 2000 at 09:22:11AM -0400, Berin Loritsch wrote:
> Is there any way (I am willing to wait for Cocoon2) to make performance
> information available to a stylesheet or XSP so that it can be displayed
> visibly or logged if more than a certain amount of time?

I think you'll almost certainly have to wait for Cocoon2, I'm
afraid - Cocoon1.x is almost frozen now, we're not adding any
major new functionality at this stage of the lifecycle.

We've been talking about a logging architecture off and on for
some time, and I think this kind of thing is perhaps best handled
as part of that. Avalon has a block (are they still called blocks?)
for logging, and it looks sane, so it might be that we borrow
some of the ideas from that. Basically, when you send something
to the logging module, you give it a level, from DEBUG, through
INFO, WARNING, ERROR, and EMERG (iirc, which I probably don't ;).

Basically, I suspect we'd log request times at the 'INFO' level,
so that they could be ignored by the logging code if the server
administrator doesn't want them.

> My proposal is that a taglib will allow you to add hooks to obtain
> information that is pertenent to debugging that tag-lib (SQL taglib
> would provide the actual query and the time it took to process, etc.).

Similarly, we could log this kind of thing at the 'DEBUG' level.

> That way you have the information available to you when you need it.
> Cocoon would use the Site-manager function to only generate that
> information to certain IP addresses (i.e. 196.168.0.241 adds the
> ?debug=1 variable to the URL or something like that).

Hmm. I'd rather avoid that in a way. I wonder if it would be better
to provide some way of getting the logged events for that request
into the result tree somehow. I can't think how to do this really,
since by the time you have the events, you've already built and
transformed the tree you were going to insert them into. Any ideas,
guys?

> That way the developer has direct access to information he needs to
> debug his code.  It will also help narrow performance problems: the
> SQL query needs to be optimized, using an inneficient XSLT structure,
> Taglib has an error, XSP code has an error, etc.

Uhuh. As I said, I certainly agree that there's a need for more
debugging, but I suspect that's better provided by a good logging
infrastructure than what you're proposing. On the other hand, I
could be wrong. Guys, what do you think?

-- 
Paul Russell                               <paul@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.

Mime
View raw message