You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@infoplanning.com> on 2000/05/23 15:22:11 UTC
Making performance information available to docs
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 ask this because of page debugging and performance enhancements are
much easier when the information is readily available to you up front.
The *one* nice thing about ColdFusion is the debug information it gives
to the developer at the end of the page. It gives you server time, SQL
queries, SQL performance times, passed variables and values, and HTTP
header information. All of these things make debugging the speghetti
code
that it forces you to write a little easier to debug.
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.). 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).
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.
Re: Making performance information available to docs
Posted by Berin Loritsch <bl...@infoplanning.com>.
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. 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?
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 <pa...@luminas.co.uk>
> Technical Director, http://www.luminas.co.uk
> Luminas Ltd.
Re: Making performance information available to docs
Posted by Paul Russell <pa...@luminas.co.uk>.
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 <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: Making performance information available to docs
Posted by Berin Loritsch <bl...@infoplanning.com>.
burtonator wrote:
> 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?
>
> Probably should be logged. I don't see how it could be done visually.
>
> > I ask this because of page debugging and performance enhancements are
> > much easier when the information is readily available to you up front.
> >
> > The *one* nice thing about ColdFusion is the debug information it gives
> > to the developer at the end of the page. It gives you server time, SQL
> > queries, SQL performance times, passed variables and values, and HTTP
> > header information. All of these things make debugging the speghetti
> > code
> > that it forces you to write a little easier to debug.
>
> Does this happen on *all* deployed systems? This seems like too much
> information... *especially* SQL queries.
>
> I smell security hole :)
It only does it on specific IP addresses that you set up. You don't have to
to turn that information reporting on if you don't want it. But anytime you
have dynamically created queries, this information is invaluable.
>
>
> > 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.). 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).
>
> It is a bigger problem than you think. you would really need to put
> this debug code into every taglib. It makes *much* more sense to just
> put JServ or Tomcat (with Cocoon and your web app) into a performance
> analysis/profile tool like JProbe or OptimizeIt.
>
> I could see a quick taglib that you could put at the begining and end of
> an XSP file to time the whole thing... that would be easy enough.
That might be good enough for now...
>
>
> Kevin
>
> --
> Kevin A Burton (burton@apache.org)
> http://relativity.yi.org
> Message to SUN: "Please Open Source Java!"
> "For evil to win is for good men to do nothing."
Re: Making performance information available to docs
Posted by burtonator <bu...@relativity.yi.org>.
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?
Probably should be logged. I don't see how it could be done visually.
> I ask this because of page debugging and performance enhancements are
> much easier when the information is readily available to you up front.
>
> The *one* nice thing about ColdFusion is the debug information it gives
> to the developer at the end of the page. It gives you server time, SQL
> queries, SQL performance times, passed variables and values, and HTTP
> header information. All of these things make debugging the speghetti
> code
> that it forces you to write a little easier to debug.
Does this happen on *all* deployed systems? This seems like too much
information... *especially* SQL queries.
I smell security hole :)
> 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.). 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).
It is a bigger problem than you think. you would really need to put
this debug code into every taglib. It makes *much* more sense to just
put JServ or Tomcat (with Cocoon and your web app) into a performance
analysis/profile tool like JProbe or OptimizeIt.
I could see a quick taglib that you could put at the begining and end of
an XSP file to time the whole thing... that would be easy enough.
Kevin
--
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."