[AGENT++] SNMP v3 get performance

[John McCaskey]

Hi Jochen,

Thanks for the additional info, see comments inline...

On 3/21/06, Jochen Katz <katz at agentpp.com> wrote:
>
> Hi John,
>
> password_to_key() takes that much CPU because it hashes over a 1MB
> buffer that is filled with the repeated password.


Ahhh that makes much more sense now, hashing the 1MB buffer is obviously not
going to be the best plan... I didn't realize it wasn't just over the
password itself so I was a little suprised how much cpu time it was taking
up.

> It does look that way, there is an SNMP->engine_id_discovery() function,
> but
>
> Yes, this was added some time ago to allow easy discovery, but it has
> the disadvantages mentioned in the docs: don't do other things with the
> Snmp object while calling this function. so I would also recommend the
> following:


Yeah, I looked at the code for it and it seemed unsafe for me to use in my
threading situation.

> perhaps I will send the request the way I am already doing it the first
> time
> > around, discover the engine id off the response, and then after that
> keep
> > the engine id around for use adding localized users for future requests
> to
> > the same device.
>
> But beside the engine id you also have to keep the localized keys, so
> you can call the add_localized_user() on later runs.


Yep, I went ahead and implemented that yesterday afternoon.  I have a struct
that contains the engine id, user_name, security_name, auth_password,
priv_password, auth_protocol, auth_key, priv_protocol, priv_key, and a
timestamp.  I'm then putting these into a std::map based of my unique id I
assign all devices to be monitored in my system.

I check the map once every so often and look for any structs that the
timestamp is way out of date and remove them from the cache as the device
may no longer be monitored.  Then in the actual SNMP polling threads I find
the cached struct if it is available and I check that the username,
security_name, auth_password, priv_password, and auth_protocol are still the
same on the device (a user may have updated the devices configuration since
we last polled it) and if so I use the cached auth_key, engine_id, and
priv_key and add a localized user.  If any of them have changed I delete the
cached data and add a non-localized user.  Then whenever I cleanup the
polling session I check if I already have the data cached, and if I don't I
get the engine_id that was discovered and add a localized user to the cache
for use in future requests.

The performance on that solution seems to be very good, on par with v1
almost. Thanks again for everyone's help with this!

Regards,
>   Jochen
>
>
>
>
>
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp
>