Michael Peters wrote:
Fred Moyer wrote:
I've been having fun with dtrace, and I most recently used it to see
what files are being accessed by mod_perl during requests. I've
preloaded all the modules in my application that I know about into
startup.pl, but when I startup my httpd server and make a request, I got
some unexpected results.
sudo rwsnoop -n httpd
501 3509 httpd R 405 http.pm
501 3509 httpd R 0 http.pm
501 3509 httpd R 2239 _server.pm
501 3509 httpd R 0 _server.pm
501 3509 httpd R 4096 _generic.pm
501 3509 httpd R 1563 _generic.pm
501 3509 httpd R 0 _generic.pm
501 3509 httpd R 2052 _query.pm
501 3509 httpd R 0 _query.pm
I've done the same thing in the past by dumping %INC to a file at startup and
then at the end of a request (using a cleanup handler) and then comparing the 2.
And I get the benefit of the full path to the file. Is there something else that
dtrace provides that my approach doesn't?
Only that the code doesn't have to be instrumented. I was surprised
that those files weren't loaded at startup, up to this point I hadn't
taken into consideration modules which were required at runtime.
There were a few other neat things I was able to do, like seeing that
mod_perl wrote to disk for $r->error calls during the request, as
opposed to waiting until after the response had been sent to the client
like the access log does. Stuff I knew was happening before, but seeing
it in action (same as when seeing the results of instrumenting my code)
make me think a bit more about the code I was writing.
