Krusty> THE PROBLEM
Krusty> The script works fine, however I have noticed that the performance
Krusty> becomes very bad if more than 300 OID's are asked for (nodes x OID's).
Krusty> I have varied all of the parameters that I could think of (i.e. lots of
Krusty> nodes few OID's, few nodes many OID's)
Krusty> I have tried various values for the window, number of nodes, number of
Krusty> OID's, how many OID's asked for at a time and have always come up with
Krusty> the limit of 300.
Krusty> Exactly what happens is:
Krusty> asking for 10 OID's takes x time to get and y time to sort
Krusty> asking for 100 OID's takes 10x time to get and 10y time to sort
Krusty> asking for 200 OID's takes 20x time to get and 20y time to sort
Krusty> etc...etc..etc..
Krusty> however
Krusty> asking for 310 OID's takes 40x to get and 40y to sort
Krusty> asking for 400 OID's takes 80x to get and 80y to sort.
Krusty> A plot of the times vs OID's in all situations tried produces the same
Krusty> result. The plot looks like a diode characteristic, or like a queueing
Krusty> problem.
Krusty> It appears to me that the script reaches some limitation in
Krusty> scotty or TCL for the amount of events outstanding in the
Krusty> eventloop or the number of requests that it can have
Krusty> outstanding.
Krusty> The machine that I have this running on is a sparc 5 with 64MB
Krusty> ram (with little else going on)
I have written my own little test script. I can't reproduce this
behavior. I have done some tests with up to 1200 async requests
against my linux snmpd (via loopback) and against two CISCO routers
(over an Ethernet). The number of milliseconds/request is more or less
constant (and it even drops in my tests against the CISCO box).
There is no build-in limitation that I am aware of. Some internal data
structures (e.g. the list of waiting async requests) will exhibit
performance that depends on the number of existing requests. However,
this kind of overhead should increase linear with the number of
requests (and I guess it is not important at all on fast machines).
Note, I did all my tests with SNMP variables that actually exist on
the target agents. If you have agents that don't respond to SNMP
requests or need considerable time to process the requested varbinds,
your measurements might be completely different due to retries and
timeouts.
Juergen
-- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)