Mib table and DB table

[Alex Finogenov]

Ron,

My comments are embedded below.

Thanks,
Alex

> -----Original Message-----
> From: Ron Sperber - Israel [mailto:RonS____gilat.com]
> Sent: Tuesday, August 21, 2001 9:54 AM
> To: 'agentpp-dl____agentpp.com'
> Subject: RE: Mib table and DB table
> 
> 
> Alex,
> Thanks AGAIN for your help, but I still at a loss:
> I thought the MibTable::Update() is the place to load all the 
> DB rows to the
> Mib tree, and thus reducing the DB access to the minimum.
> If I use the MibTable::find_succ() function than I'll access 
> the DB for each
> VB in the GetNext request and in a big DB I don't think the 
> performance
> would be good.

I am talking about a stateless system that does not keep its state between
requests, i.e. the agent preloads necessary values at the beginning or
during each request, and trashes the results after flushing them to the
interfacing systems at the end of each request.

You have to design your agent to access your DB only once for each needed
bit of information (cache index-to-object or index-to-value relationship for
all the queries values, even the failed once; this will allow you never to
repeat the same step again). In such a system the difference should not be
significant whether you load your rows at the beginning of a request, or in
the middle of the request processing. In some systems this may not be true
due to overhead for initiating a query/connection, processing result set,
etc. In my system this has not been an issue (so far). If this is an issue
for you, you may have to code update() to populate your rows. Then you will
have to code update() for GetBulk, and GetNext will come for free for the
case of non-repeaters=request size, or max-repetitions=1. This is trickier
than using find_succ(), but is not very hard.

> In addition, the DB can be changed not only through SNMP, so 
> I can't be sure
> that all previous rows in the Mib tree still exists in the DB 
> (which meant I
> had to remove all the rows from the table in each GetNext request).

If your agent has project a state of another system, you have to make sure
that it is accurately reflecting the state of that system in each request.
This may be done either a hard way by synchronizing every change in both
systems, or it can be done easier by not keeping any state in the agent
between requests, i.e. have it stateless. But keeping the same state across
each request is very important (i.e. each request must show a static
snapshot of the system). I chose the latter approach. If you have hard
performance requirements *AND* you are confident (from profiling or
prototyping, not by simply guessing) that the stateless agent approach is
too inefficient for you, you may have to trade off simplicity for
performance.

> Again any help would be highly appreciated,
> TIA,
> 	Ron
> 
> 
> > -----Original Message-----
> > From: Alex Finogenov [mailto:afinogenov____malibunet.com]
> > Sent: Monday, August 20, 2001 6:40 PM
> > To: 'Ron Sperber - Israel'; 'agentpp-dl____agentpp.com'
> > Subject: RE: Mib table and DB table
> > 
> > 
> > Ron,
> > 
> > Multi-threaded agent would add a bit of complexity. At this 
> > point I am not
> > worrying about this because I am not sure how much benefit 
> > would the MT
> > solution bring. If I had to move to an MT solution, I would have to
> > implement my own context switching of the table's state since 
> > tables in
> > Agent++ are singletons.
> > 
> > Initially I tried to work with recommended MibComplexEntry, 
> > but I came to
> > conclusion that I have to add much more code than if I simply 
> > Decorate the
> > MibTable.
> > 
> > Regarding GetBulk - if you implement GetNext, you get GetBulk 
> > for free. You
> > can implement GetNext in a number of ways, but extending
> > MibTable::find_succ() seems to be the simplest. The idea is 
> > that the agent++
> > calls find_succ() every time it needs to get the next object. 
> > My version of
> > find_succ() loads the next object into its respective row (if 
> > the object
> > exists), then calls MibTable::find_succ() to finish the job. You can
> > implement a number of optimizations here, depending on your system's
> > requirements and how stateful it is (caching of the accessed 
> > objects, etc.)
> > Don't forget to try to load the first object in a table if 
> > the "next" object
> > is not found, or you won't get the required behavior.
> > 
> > Alex
> > 
> >
> > 
>