Re^4: Timer implementation

My application is CGI script that works with SQLite and does a lot of text manipulation works.
Of course i need wall clock to know is it my script works so slowly or it is slow network throughput.
If script works slowly, then i will know that i need to do some code optimization.
But if i got situation where real time is much more bigger than sys+real time. What to do in this case? And is it possible case? If I understand correctly it's possible at case where CPU is busy by other process or my process is sleeping on I/O system calls. If it's true - robust timer should include all three number - real, system and user times. Am i right?

Comment on Re^4: Timer implementation

Replies are listed 'Best First'.
Re^5: Timer implementation by GrandFather (Saint) on Sep 16, 2008 at 03:19 UTC
So your "application" is "timing server side performance for a CGI script". If you are interested in perceived slowness by a real user then any time period less than 1/2 a second is uninteresting. Trying to measure times with 1 ms resolution in that context is neither meaningful nor useful. Wall clock time for the server process is the only thing of interest to a "someone" at the far end of the pipe and that can be obtained using Time::HiRes::gettimeofday. If you determine that there is a performance issue on the server then you have the harder task of determining where the bottle neck is. Perl reduces RSI - it saves typing	[reply]
Re^5: Timer implementation by shmem (Chancellor) on Sep 16, 2008 at 22:09 UTC
Real time is the real time elapsed. System time is the time the kernel has been busy with your system calls. User time is the time spent in user space. `systime + usertime = realtime` is true only if your process is the only process on the box, and if the kernel does all its fiddlings in no time. But you aren't interested in absolute times, but in relative - to identify bottlenecks. To do so, time chunks of your application using Time::HiRes. Separate CPU intensive tasks from disk (also database) I/O and network I/O. You might want to run certain tasks in "dry run mode", eliminating I/O as much as possible. The sums of elapsed times will give you hints, but of course, those can be grossly distorted by other tasks running with higher priority than the ones you are observing.	[reply] [d/l]
Re^5: Timer implementation by cramdorgi (Acolyte) on Sep 16, 2008 at 09:42 UTC
Er... wasn't it so that the user and system times only concern the current process, not its possible children? That's my reading of the man page, and has been my belief so far. The real time of course does take the children into account...	[reply]
Re^6: Timer implementation by bash (Scribe) on Sep 16, 2008 at 13:47 UTC
Nope, my process doesn have any children. Real time count sleep time, this is why real-time will be always >= then sys+user time )	[reply]