Speed of pysnmp

Roy Smith roy at panix.com
Sun Jul 11 02:04:27 CEST 2004


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.

The switch is back in my office; I'm sitting at home running this on my 
Mac OSX box, through a VLAN connection over DSL.  Ping times are around 
40ms:

--- 192.168.1.1 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 37.597/39.801/41.902 ms

The results are rather surprising (I ran these several times; the 
numbers below are fairly typical):

$ time ./get.py > get.out
real    0m9.045s
user    0m1.010s
sys     0m0.510s

$ time snmpwalk -v1 -c public 192.168.1.1 ifDescr > snmpwalk.out
real    0m3.896s
user    0m0.120s
sys     0m0.130s

The two output files had identical information (except for trivial 
output formatting differences).  There were a total of 73 rows.

It's entirely expected that the pysnmp version had much higher CPU times 
(from about 0.25 to 1.5 total user+sys).  What I don't understand is why 
the real time went up so much, from about 4 seconds to about 9 seconds.  
Most of the time doing a mib walk is waiting for UDP packets on the wire.

If the ping RTT is 40ms, and there's 73 rows, that's 2.9 seconds, which 
accounts for about 3/4 of the real time.  Add in a 1/4 second of CPU at 
this end, figure the same at the other end, a few ms for process 
switching for each packet, and it's easy to see where all the time goes.

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?



More information about the Python-list mailing list