On Sat, Dec 15, 2001 at 08:57:30PM -0500, Perrin Harkins wrote:
> > One place that Rob and I still haven't found a good solution for
> profiling
> > is trying to work out whether we should be focussing on optimising our
> > mod_perl code, or our IMAP config, or our MySQL DB, or our SMTP setup,
> or
> > our daemons' code, or...
>
> Assuming that the mod_perl app is the front-end for users and that
> you're trying to optimize for speed of responses, you should just use
> DProf to tell you which subroutines are using the most wall clock time.
> (I think it's dprofpp -t or something. Check the man page.) If the sub
> that uses IMAP is the slowest, then work on speeding up your IMAP server
> or the way you access it.
> CPU utilization may not be all that telling, since database stuff often
> takes the longest but doesn't burn much CPU.
I agree 100%, wall clock time is the best metric. Consider that most
apps are not CPU bound, they are I/O or network bound. Wall clock
time measures that exactly.
Another useful tool is truss/strace. Start up your server single
process (-X) and then attach to it with strace. The -c and -r flags
to strace are quite handy.. For example here's the cumulative stats
for 'ls'
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
52.29 0.004508 751 6 read
19.48 0.001679 560 3 write
12.93 0.001115 56 20 close
6.01 0.000518 23 23 old_mmap
5.45 0.000470 21 22 2 open
1.22 0.000105 21 5 munmap
0.93 0.000080 40 2 getdents64
0.71 0.000061 3 21 fstat64
0.29 0.000025 4 7 brk
0.24 0.000021 11 2 mprotect
0.19 0.000016 8 2 ioctl
0.12 0.000010 10 1 uname
0.09 0.000008 3 3 2 rt_sigaction
0.06 0.000005 5 1 fcntl64
------ ----------- ----------- --------- --------- ----------------
100.00 0.008621 118 4 total
--
Paul Lindner [EMAIL PROTECTED] ||||| | | | | | | | | |
mod_perl Developer's Cookbook http://www.modperlcookbook.org
Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
