cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Making performance information available to docs
Date Tue, 23 May 2000 15:22:20 GMT

Paul Russell wrote:

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

Understandable.  I don't want to hold things up.

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

If we can get the logged info into the result tree, that would be good.
My problem is that I have to look in two different places everytime
I want to view my changes.

I could right a debug XSP page that showed the request params and
such, but overall processing times would be good if it could be included
in a visible tag instead of a comment.

How about a namespace deal like this:
<cocoon:message /> to be able to grab the message passed in XSLT.
<cocoon:log level="INFO" /> to be able to grab the log info.
   it would expand to <cocoon:log-entry>entry info</cocoon:log-entry>
   for each entry so that XSLT can transform it.

Architecturally, I don't know how that would work out.  It would be
important to be able to turn the functionality off when it is time in
released code (increase performance).  Having all this information
available during test time is important though.

Maybe we could create a debug taglib that could be included when
you needed it, but excluded when you didn't.  Cocoon would need
the proper hooks to make it available though.

> > 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                               <>
> Technical Director,         
> Luminas Ltd.

View raw message