[AGENT++] Asynchronous interface in SNMP++

[Marek Malowidzki]

>  > [ sync/async performance tests]
>
> Did you test using one Snmp object or did each thread use its own Snmp
> object?

Good question. All threads share the same, single Snmp object.

Currently, I have implemented three tests:

1.) Synchronous: multiple threads are blocked on a request (say, get-next).
This is the slowest one.

2.) Asynchronous: a number of "activities" (suimulating thread behavior,
that is, some execution flow) are performing SNMP walk. A single thread
waits for events and processes them calling
m_snmp->eventListHolder->SNMPProcessEvents(blockMsec). Callbacks are
processed on threads from Win2k's system pool. This is about 2,5 times
faster.

3.) Mixed: synchronous thread behavior with asynchronous SNMP++ processing.
Multiple threads use the asynchronous interface but instead of specifying
callbacks to invoke, they wait blocked for the requests to finish (they use
an event object and wait for it to become signaled). This is 10 (ten!) times
faster. Unless there is some obvious mistake in my measurements, it looks
like the native SNMP++ synchronous interface is really inefficient.

Note that the tests were performed in .NET environment, which may affect
results.

> > I believe that fixing this behavior would not be that difficult (do not
> > press you to do it immediately, just theoretizing ;-) ) - the threads
should
> > be waiting on a semaphore/event type object untill the event processing
> > thread wakes them up (and no more need to walk the list of events) or
the
> > timeout expires. The event list could be replaced with a hashtable
indexed
> > with the request_id. Etc. Under this model, I would expect the
difference in
> > performance to be a lot smaller (say 10%).
>
> I do fully agree, that the event code must be completely rewritten. At
> the moment I just don't have the time to do it...

That's ok.

I just want to add that what brings the real complexity is the fact that
SNMP++ supports various operating systems, so much testing is needed. Under
Windows, for example, I think it would be quite easy to do this (e.g., as
described above), as the event structures could be augmented with some wait
object, which would be signaled to the waiting thread (no need to poll the
event queue).

Marek