Speed of pysnmp

[Anthony Baxter]

On Sat, 10 Jul 2004 20:04:27 -0400, Roy Smith <roy at panix.com> wrote:
> There's been some talk recently about the relative speeds of the various
> python SNMP libraries.  I just did a little benchmarking, and got some
> surprising results.
> 
> I downloaded pysnmp-3.4.2 and build a little mib walk application around
> it.  I used it to walk ifDescr on an Extreme Summit 48i (48 port
> ethernet switch).  I did the same thing using snmpwalk from net-snmp
> 5.0.8.

> [snip]

> But, where does the additional 5 seconds of real time come from for the
> pysnmp version?  I burned another 1-1/4 seconds of CPU at my end, but
> everything else really should be the same.  The network doesn't know
> what kind of code built the packets.  Neither does the box at the other
> end.  Something's inserting another 50ms or so delay per packet which is
> not accounted for my the CPU time.  Anybody have any ideas where that
> might be coming from?

Try profiling the pysnmp code, see where the time is being taken.

>From past, bitter experience, I can say that you can make a massive
massive difference in any SNMP application by carefully constructing 
your getnext packets - don't just get things one at a time. Do some 
rough calculations on how many entries you can fit in a packet, and 
getnext multiple things at once. If you're walking a table of more than
one column, start at the top of each column and getnext in parallel. 
If it's just one column, hopefully you can find out how many entries
are in the table. Start off at 0, 25%, 50% and 75% of the table, and 
walk it in parallel. The SnmpTable code in the (very old, and now 
abandoned) snmpy package had all sorts of evil smarts for dealing
with this stuff. I believe it got ported across to pysnmp, but I've been
blissfully able to avoid SNMP for about 5 years now, so I haven't 
touched it at all.