Rauznitz Balazs <[EMAIL PROTECTED]> writes:
> Apache::DProf adds relatively small overhead as it only profiles at
> function level. I found SmallProf to be very expensive; it at least
> doubled the execution times, which is quite understandable if you want
> line level profiling. Maybe a combination of the two would be the best.
>
> Another issue is stability; I get random coredumps trying to use DProf,
> which usually means that the gathered profiling data is lost for that
> httpd child. AFAIK there is no way to make DProf flush gathered data
> before the child actually exists.
Ok, I've tried it and I saw the same things you did. The load did increase but
the web server was still usable. Most of the increase in load was probably
from having to fork new servers so quickly as the old ones seg faulted. About
1/4 of the processes would seg fault immediately after forking, of the others
some seem to have been ok, at least some of the profile data is ok so either
the exited normally or they just got lucky and seg faulted outside of a
handler.
This is really unfortunate, it means most of my profile dumps are useless
because it aborted in the middle of a call. Still I got some useful data. It
just means I can't leave it running and collect ongoing data.
Is anyone actively hacking on DProf? Are they interested in the core dumps?
There's also some data I'm looking for that dprofpp doesn't show, like the
worst-case and best-case stats for each function, and the ability to
consolidate lots of tmon files into a single report. I guess I'll look at
doing these things, since it looks like it just parses a text file for the
stats, it shouldn't be hard.
--
greg
