[erlang-questions] Performance issue with snmp

Dmitry Kolesnikov dmkolesnikov@REDACTED
Tue Jan 10 23:28:03 CET 2012


I am sorry not been able to comment Erlang side of snmp but I had exactly the same issue with snmp in other runtime. There was two performance bottleneckes
1. within the interface to snmp protocol
2. the way how application issues GET request (two much of rtts)

The best option for me was bulk get requests for desired sub tree(s) and then I run client side filtering and post processing.

If you think that in your case root cause is issue #1 then I would advise to sniff snmp traffic to validate it.


On 10.1.2012, at 23.25, Phillip Toland <phil.toland@REDACTED> wrote:

> I am working on an application that uses SNMP heavily. This
> application needs to make hundreds of SNMP queries during normal
> operation and, this being Erlang, I tried to speed things up by
> issuing queries in parallel. Unfortunately, the performance of snmpm
> decreases considerably as you add more concurrent requests with
> requests timing out above a certain threshold.  To illustrate the
> problem I have created a minimal code sample to reproduce the problem.
> Since snmpm requires a little configuration I have uploaded the code
> and config files to Github: https://github.com/toland/snmp_perf
> If I run snmp_perf:sync() with any number performance is very stable
> with every request returning in about 0.002 seconds. I am testing with
> a device on the network so this is reasonable performance. However,
> running snmp_perf:async(10) results in requests taking on average 0.01
> seconds and the performance continues to get worse until about 80
> concurrent requests when I start getting timeouts and the average
> request time is about 0.08 seconds. Increasing the number of requests
> results in longer request times and more timeouts.
> My question is this: is this performance degradation the expected
> behavior or does it represent a bug in snmpm? It looks like a bug to
> me but I wanted to get a second opinion. If this is the expected
> behavior does anyone have a suggestion for ameliorating the problem in
> a highly concurrent application? I have considered implementing a
> queue and worker pool as a way to limit the concurrent requests to
> snmpm, but was hoping there was a better solution.
> Thanks
> ~p
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list