Hi,
I have been using the Ruby PCAP module to implement a simple network
traffic
flow meter based on the RTFM architecture. When I run my meter with the
Ruby
profiler option, I have discovered that the biggest single chunk of
processing
time goes to calls to the “each” function of the Range class, with calls
to
this method accounting for up to 23% of total processing time when the
meter
reads traffic data off trace files. This figure is approximately halved
when
the meter reads traffic off a live interface. I have checked my code, as
well
as the pcap_misc.rb and pcaplet.rb files within the Ruby PCAP module and
I am
not sure where these calls are being made. I was wondering if anyone
familiar
with the Ruby PCAP module could inform me where the call to Range.each
is being
made as
I am now in the process of trying to improve my meter’s performance.
Thank you
for your time.
cheers,
Damir
Hi,
I have been using the Ruby PCAP module to implement a simple network
traffic
flow meter based on the RTFM architecture. When I run my meter with the
Ruby
profiler option, I have discovered that the biggest single chunk of
processing
time goes to calls to the “each” function of the Range class, with calls
to
this method accounting for up to 23% of total processing time when the
meter
reads traffic data off trace files. This figure is approximately halved
when
the meter reads traffic off a live interface. I have checked my code, as
well
as the pcap_misc.rb and pcaplet.rb files within the Ruby PCAP module and
I am
not sure where these calls are being made. I was wondering if anyone
familiar
with the Ruby PCAP module could inform me where the call to Range.each
is being
made as I am now in the process of trying to improve my meter’s
performance.
Thank you for your time.
cheers,
Damir
Just speculation: it’d guess that the each method of Capture
gets called once for every packet. That would explain why it’s called
so often. When you load a capture from a file, it may get called once
while loading each packet and once when you loop through them, which
would explain the halfing during live captures.
Provide the relevant bits of code and traces and we might be able to
make further guesses…
-tim