On 15 March 2010 10:29, bai haoquan <baihaoq...@gmail.com> wrote: > To my understanding, it will cause performance problem when there are mass > of data.
Yes - the iterator helper is notoriously inefficient for large tables. It's probably not a sensible choice if performance is an issue. Use one of the other helpers instead. > I have no idea that why we have to traverse > the whole 200 nodes every time to get a value Remember that the iterator helper was specifically designed for tables where the data is stored in "random" order. So the expectation is that you'd always have to search the whole internal table, in order to find the "next row" in SNMP ordering. There is a flag that can improve performance if the internal indexing matches the SNMP ordering, but it's still probably not the most efficient of the helpers. Remember too that the "get_first/get_next" loop is run for each individual GETNEXT request. The "get_next" calls do *NOT* correspond one-to-one with the incoming GETNEXT requests of the snmpwalk or snmptable command. > Do I have any misunderstanding? Look forward to your early reply and > some good advices for this problem. My best advice is to use a different helper! Dave ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
