Speed of pysnmp
roy at panix.com
Tue Jul 13 14:44:50 CEST 2004
In article <cd069f$r8c$1 at news.rol.ru>, Ilya Etingof <ilya at glas.net>
> Roy Smith <roy at panix.com> wrote:
> [ skipped ]
> > 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.
> My guess is that Python code takes up so much CPU time on a single SNMP
> processing, that OS's likely to schedule out (involuntarily context switch)
> process for greater number of times than it is with C version.
> In other words, if you burn 0.01 CPU sec, you're likely to get it done within
> process's time slice. Although, when you burn 10 CPU secs in bulk, you're
> to 1) run out of process's time slice (context switch) 2) compete for CPU
> with other processes on the system. In the end, both factors might contribute
> to real time increase...
It turned out to be less complicated than that. In fact, it turned out
to be so simple that I canceled my articled about 2 minutes after I
posted it, but I guess it escaped before I got to it!
The problem turned out that in my python code, I was doing a getNext to
get the next oid, then a get for the value of that oid, so I was
generating twice as many packets as I needed to!
Why was I doing such a dumb thing? Because I was using a style I had
gotten used to in another system I'd worked with which caches the values
of getNext's. My code didn't have the cache, so I went out to the
network to satisfy the second request. Dumb, dumb, dumb.
More information about the Python-list