[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flowscan
Subject:    Re: flowscan benchmark module
From:       Dave Plonka <plonka () doit ! wisc ! edu>
Date:       2002-01-16 18:41:27
[Download RAW message or body]


Hi Matt,

response below...

On Wed, Jan 16, 2002 at 12:57:41PM -0500, Matt Selsky wrote:
> > I would be tempted to do that test like this:
> > 
> > $ time flowdumper -cn flows.YYYYMMDD_HH:MI:SS+TZ
> > 
> > Does that yield approx. the same real/CPU time as "flowscan Nothing"?
> 
> $ flowscan -v Nothing
> 2002/01/16 12:49:20 working on file /cflow/flows/flows.20020116_12:30:34-0500...
> 2002/01/16 12:49:38 flowscan-1.020 Nothing: Cflow::find took 18 wallclock secs \
> (18.20 usr +  0.21 sys = 18.41 CPU) for 33665335 flow file bytes, flow hit ratio: \
> 0/612097 2002/01/16 12:49:38 flowscan-1.020 Nothing: report took  0 wallclock secs \
> ( 0.00 usr +  0.00 sys =  0.00 CPU) 
> $ time flowdumper -cn  flows.20020116_12\:30\:34-0500 
> matched 612097 of 612097 flows
> 
> real    0m6.442s
> user    0m6.100s
> sys     0m0.310s
> 
> flowscan: 34K flows/second
> flowdumper: 87K flows/second
> 
> Flowscan takes longer and is a better baseline for the fastest possible 
> rate that flowscan can do.  flowdumper doesn't take into account the 
> other overhead that flowscan does.

Hmm, I had never tried such a test before... I would have thought that
the flowscan overhead for a report that does "Nothing" would be only
about the same as having flowdumper print 'n'othing, since they're
almost the same in that they call Cflow::find passing a reference to a
trivial "wanted" function.

Maybe I need to reacquaint myself with the perl profiler to see if
there's a quick optimization somewhere in the "flowscan" script
itself.  Just thinking out loud, but perhaps it's here - I wonder how
much the can("wanted") test costs:

   foreach (@objects) {
      next unless ($_->can('wanted'));
      if ($_->wanted) {
         $rv = 1
      }
   }

That "next unless ..." line could be removed from the loop if you know
that all your report modules have a "wanted" subroutine.  (If we find
that to be faster, I can call can("wanted") just once during
initialization, rather than once per flow as it does now.)

Perhaps, during initialization, flowscan could unroll that "foreach"
loop by writing the wanted subroutine dynamically, then instantiating
it with eval.

I'll try some tests with your "Nothing" report.

Thanks,
Dave

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe flowscan" in message body
Archive     http://net.doit.wisc.edu/~plonka/list/flowscan/archive/


[prev in list] [next in list] [prev in thread] [next in thread]