Speed of pysnmp

[Roy Smith]

In article <cd069f$r8c$1 at news.rol.ru>, Ilya Etingof <ilya at glas.net> 
wrote:

> 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 
> message
> processing, that OS's likely to schedule out (involuntarily context switch) 
> python
> 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 
> a
> process's time slice. Although, when you burn 10 CPU secs in bulk, you're 
> likely 
> to 1) run out of process's time slice (context switch) 2) compete for CPU 
> time
> with other processes on the system. In the end, both factors might contribute 
> to real time increase...
> 
> -ilya

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.