Re^3: Timer implementation

Your implementation context is CGI script, but that is not your application. Your application may be timing a database query or some such. So, what is the application?

You need to decide what it is that you want to report - wall clock time or process time.

With most operating systems that are not designed for real time environments reporting wall clock times of less than a few milliseconds is fairly meaningless because time slices for tasks are of that order and will render any real time reporting at that level meaningless.

Perl reduces RSI - it saves typing

Comment on Re^3: Timer implementation

Replies are listed 'Best First'.
Re^4: Timer implementation by bash (Scribe) on Sep 16, 2008 at 02:53 UTC
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?	[reply]
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 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]
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]