Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
PerlMonks ing -- and a little confused

by Sifmole (Chaplain)
on Mar 14, 2005 at 21:39 UTC ( #439460=perlquestion: print w/replies, xml ) Need Help??
Sifmole has asked for the wisdom of the Perl Monks concerning the following question:

The following block of cmpthese prints are confusing me a bit. If you look at the wallclock seconds there are very large ( 70% to 80% ) differences in time. However, the comparison percentages are 10% or less. Can someone explain to me what I am misunderstanding?
Benchmark: timing 100 iterations of smMod, smPlain... smMod: 198.103 wallclock secs (20.84 usr + 0.32 sys = 21.16 CPU) + @ 4.72/s (n=100) smPlain: 1013.47 wallclock secs (22.88 usr + 0.39 sys = 23.27 CPU) + @ 4.30/s (n=100) Rate smPlain smMod smPlain 4.30/s -- -9% smMod 4.72/s 10% -- Benchmark: timing 100 iterations of seMod, sePlain... seMod: 161.968 wallclock secs (65.76 usr + 0.42 sys = 66.18 CPU) + @ 1.51/s (n=100) sePlain: 435.528 wallclock secs (71.20 usr + 0.43 sys = 71.62 CPU) + @ 1.40/s (n=100) Rate sePlain seMod sePlain 1.40/s -- -8% seMod 1.51/s 8% -- Benchmark: timing 100 iterations of navMod, navPlain... navMod: 77.0209 wallclock secs (14.74 usr + 0.20 sys = 14.95 CPU) + @ 6.69/s (n=100) navPlain: 317.475 wallclock secs (14.70 usr + 0.38 sys = 15.09 CPU) + @ 6.63/s (n=100) Rate navPlain navMod navPlain 6.63/s -- -1% navMod 6.69/s 1% --
As a note, in case anybody wonders or it is relevant, the different functions are requesting the same pages from two different servers. One is running mod_perl and the other is vanilla CGI. Thanks in advance

Replies are listed 'Best First'.
Re: ing -- and a little confused
by Roy Johnson (Monsignor) on Mar 14, 2005 at 21:49 UTC
    It's comparing CPU time, which is a better measure of how long it takes your program to run than ordinary time.

    Caution: Contents may have been coded under pressure.
      So I guess, because a large portion of the actual processing time is on a remote server and the local server is just waiting for most of it's "wallclock" time that is the reason for the large difference in percentages?

      So in this case the wallclock time would actually be a better gauge of the comparison than the CPU time, right?

        Yes, if the code of interest is being run on a remote machine, then wallclock seconds are your best measure.

        Caution: Contents may have been coded under pressure.
Re: ing -- and a little confused
by Joost (Canon) on Mar 14, 2005 at 21:58 UTC
    If you are requestion pages from machines other than the tests are run on, the user/sys times are not relevant (if the requests are done the same way). The user/sys time is the amount of CPU time the tests take to run. If a process is waiting for something in a syscall (i.e. waiting for network input) the scheduler usually switches to anytother process, so the actual CPU time for that process will not increase. The wallclock will increase, since that is the actual amount of physical time that is spend (the clock on the wall).

    In other words, if you want to measure the responsiveness of your servers, your current setup is good, and you can more or less disregard the CPU time on your test machine and just watch the wallclock time. You should make sure you get no interference from other processes on your test machine and servers, though.

    One of the advantages of measuring in CPU time is that if your machine is really busy running other processes, the CPU time for a test will not be influenced by it. But it doesn't really work "cross-process" and "cross-network".

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://439460]
Approved by Joost
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (14)
As of 2017-02-28 13:05 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (399 votes). Check out past polls.