2009/4/2 Kang Chen <[email protected]>:
> I used to use mib2c.iterate.conf, but I found the efficiency of this
> framework is too slow.
> So, how about the efficiency of mib2c.table_data.conf?
Regardless of the template that you choose, there are two (or possibly
three) basic approaches to processing a table request.
One is to search through all the rows of the table, until you find
the appropriate row for the request being processed. This is the
approach used by mib2c.iterate.conf (and the iterative style of MfD).
It has the advantage that the underlying subsystem doesn't
need to know anything about the indexing used for the MIB.
It has the disadvantage that it's relatively inefficient.
The second is to hold an internal cached representation of the table
within the agent. This is the approach used by mib2c.table_data.conf
(and the non-iterative style of MfD).
Because the agent knows exactly which rows are valid, it can
determine the appropriate row directly, and so is much faster.
The main disadvantage is that the agent is working with a cached
version of the table data, which is inherently somewhat stale.
(The third approach is to have the underlying subsystem return
the appropriate "next row" for each request. This is of comparable
efficiency to the internal cache approach, but does require the
subsystem to know about the MIB index ordering).
OK?
Dave
------------------------------------------------------------------------------
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
