Graham Dumpleton wrote ..
> Graham Dumpleton wrote ..
> > One of things I used to do when I was testing this, was to use some of
> > the dependency information to produce 'dot' graph definition files and
> > view them in GraphViz on the Mac. Quite interesting. I should resurrect
> > the code and post it on the mailing list so people can play with it.
>
> Okay, I couldn't find it, but I have written a new version from scratch.
> My original used to look at whole cache for process. This one looks at
> just the modules used by a specific request. To use it, just specify a
> PythonLogHandler which calls the handler below.
Here is a slightly more refined version.
from mod_python import apache, importer
import time
def loghandler(req):
req.log_error('loghandler')
output = file('/tmp/request.dot', 'w')
modules = importer._get_modules_cache()
print >> output, 'digraph REQUEST {'
print >> output, 'node [shape=box];'
for module in modules.values():
name1 = module.__name__
file1 = module.__file__
mtime1 = module.__mp_info__.cache.mtime
time1 = time.asctime(time.localtime(mtime1))
direct1 = module.__mp_info__.cache.direct
indirect1 = module.__mp_info__.cache.indirect
generation1 = module.__mp_info__.cache.generation
print >> output, '%s [label="%s\\n%d - %s - %d - %d"];' % \
(name1, file1, generation1, time1, direct1, indirect1)
children = module.__mp_info__.children
for child in children:
name2 = modules[child].__name__
print >> output, '%s -> %s' % (name1, name2)
print >> output, '}'
output.close()
return apache.OK
This one also shows the generation number which is quite important
as it is this which is used more than file modification times to determine
if children have changed and parents should be reloaded.
Do not though that anything displayed out of __mp_info__.cache may
not be totally accurate, as that information reflects the current state
of the cache and not what it was at the time that the module loading
occurred for the specific request. Thus, if there are lots of other
requests happening in parallel, the direct/indirect hit counts may
not be what you expect.
Except for where loops are occurring, a child of a module should always
have a lower generation count.
BTW, the direct hit counter is incremented when the module is first
loaded and when that module is the root module being imported. The
indirect hit count is where a module is consulted due to being some
descendent child of the root.
Play around and you might get the idea. The counts were principally
for debugging, but when we know that this all works okay, we could
deleted that tracking code to make it run a miniscule faster.
Graham
