Re: Loading time of scotty

Doug Hughes (Doug.Hughes@Eng.Auburn.EDU)
Wed, 19 Mar 1997 13:46:37 -0600

Indeed, I think the simplest and most effective solution (as already mentioned)
is to just have the person with the startup slowness comment out the mibs
that he/she doesn't need. Dynamic loading might be okay, but it seems it would
require a lot of work for little gain. Would there be a big advantage to
doing so? (question) - Not I think for me, but perhaps for others.

>Doug> I think a memory caching tcp/udp mechanism might be interesting though.
>Doug> The first lookup would perhaps take a slight hit, but then it would
>Doug> be cached in memory for later use. The server process would serve
>Doug> up MIBS as needed from a memory base.
>
>What are we going to optimize?
>
>a) Memory usage by the Tnm extension?
>b) Startup time (or better MIB loading time) of the Tnm extension?
>c) Both?
>

I don't think memory usage was an issue (but I could be wrong), but the
startup time. At worst (all mibs loaded into memory) I don't think the memory
usage would be any more than loading all the mibs as it is now. It's hard
to know the tradeoffs of this approach without implementation. It may
turn out to be just as slow (going over the network to get the mibs) as
loading them all up to begin with. My intuition tells me that jobs that
only needed a couple of mibs would be faster, and jobs that used just about
every mib would be slower than how it is now.
But, you get the same tradeoff by just commenting out the load in the
init.tcl, so there may be no point (except that a central mib repository
could be advantageous where multiple platforms need to run scotty so you
don't have to add mibs to all your OS's - separate issue though)

--
!! 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.