Robert> I'd like some input on the following:
Robert> - What is the maximum number of SNMP requests that can be out
Robert> at once?
The upper limit only depends on the speed of your workstation.
Robert> - What is the maximum number of SNMP requests that should be
Robert> out at once?
There are two things here. First, you want to make sure that you do
not "overload" a target agent. Seconds, you want to make sure that the
SNMP traffic generated is not bulky so that it can cause problems in
the network (e.g. a router dropping a chunk of SNMP requests just
because they arrive to fast). The Tnm extension has parameters to deal
with this. You can set a window size for each SNMP session. The SNMP
engine will queue async SNMP requests if you reach the window
size. This means that your script is free to generate hundreds of
requests to a single device in a loop - the SNMP engine will make sure
that you don't get bulky traffic by delaying them if needed. The
second parameter is the delay session option. It ensures that there is
a minimum delay between two successive async requests. This helps to
further shape the SNMP traffic generated and greatly helps routers to
forward requests in cases where you have different link speeds.
Robert> - Does it take a lot of additional memory to spawn off another
Robert> Tcl process, (Would 100 or so of them take up a huge chunk of
Robert> memory?) given that the shell has TclX, Itcl, Tnm, and
Robert> Sybtcl. . all dynamically loaded?
A good UNIX system will share the memory that can be shared between
the processes. But I guess there is enough left which, multiplied by
100, still makes up an impressing number.
Robert> - Given that each returned value executes around 50 lines of
Robert> code, is it reasonable to assume that 100 devices being polled
Robert> for 25 values would not cause the code to always be waiting
Robert> for some code to finish (ie, it's not in the event loop, but
Robert> waiting for some code to finish). How about 50 values? How
Robert> about 100?
Depends on the polling interval, the response time of your agents and
the speed of your workstation I would guess.
I think you should simply write your scripts with both models in
mind. That is, your polling script handles N devices. You write
another script which splits the total number of devices M into smaller
pieces. So you end up having M/N processes where each process polls N
devices. (You may want to split the devices up by priority or by
polling interval or whatever.)
BTW, you might want to design the scripts so that they are not running
continuously but restarted from time to time (e.g. using cron). My
experience is that this makes your polling system much more reliable
because it will handle rare errors in your script and it will protect
you from nasty things like memory leaks etc. (I am not saying that
there are any memory leaks I know of. But "rejuvenation" is generally
a good idea for long running applications.) Just my $0.02.
Juergen
-- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289)-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.