On 2001.04.29, carl garland <[EMAIL PROTECTED]> wrote:
> >Great presentation! Clearly, I haven't looked at the UrlTracking
> >config. option -- it's not even in my config. file so I don't think
> >I ever would have known about it.
>
> Thanks and oops, the UrlTracking config param was just another
> parameter that I added so as to add the ability to not have the
> overhead of running the filter on production systems that dont need this
> profiling. Just add the param in the main config file.
> I need to make clearer that it is not a normal option.
Carl,
What's strange, is that in my nsd.tcl I've always had these lines
in and they don't seem to have any effect:
ns_param globalstats on
ns_param urlstats on
ns_param maxurlstats 1000
I have a vague recollection of reading (on this mailing list, a
long while back) that these settings are no longer used. I thought
your presentation was referring to these in some way.
Implementing profiling with two trace filters and an nsv memory
array is just the idea I started forming -- good to see that you've
proven that it can work, at least for dynamic analysis at the URL
level! I guess I could start with what you've done, clean up the
code, and start looking at what kind of hooks I'd need in order to
get the Tcl interpreter to log the same kind of information about
indivual proc calls (perhaps even including ALL proc calls) --
using an nsv is a great idea that I didn't think of, immediately.
One concern: does the nsv implementation use mutexes? This will
affect the way the trace filters must be written to avoid logging
lock contention as part of a URL's performance, artificially
bloating numbers in a non-linear way.
- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
