RE: query to dsx1Intervaltable always kills the subagent

Hi,
	Eventually we needed to group the requests and ask the platform for data to address this issue. This still takes time but works fine.

Sorry that I did not update the forum as some efforts went in to solve this issue from framework point of view, which is not successful so far.

Regards,
Malathi
-----Original Message-----
From: Malathi Panyam [mailto:[email protected]] 
Sent: Tuesday, March 29, 2011 9:39 AM
To: Dave Shield
Cc: [email protected]
Subject: RE: query to dsx1Intervaltable always kills the subagent

Hi Dave,
        Thanks for your reply. I used the table_data helpers framework.

We used to follow the option "b", by loading some of the data before and populating others only on request, but there are some framework changes went in the overall system, which will not allow this to happen.

We use TIPC communication between different modules and currently trying to look at why other module has to take that much time to respond.

I will update the forum once we figure this out.

Regards,
Malathi

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave Shield
Sent: Tuesday, March 29, 2011 1:01 AM
To: Malathi Panyam
Cc: [email protected]
Subject: Re: query to dsx1Intervaltable always kills the subagent

On 29 March 2011 00:25, Malathi Panyam <[email protected]> wrote:
> Our subagent process is taking more time to gather the data
> (for 768 rows to be populated), before sending the response to agent.

A couple of approaches spring to mind here:

  a)  cache the data so that the subagent doesn't have to load all 700+ rows
       every time.   (although that doesn't help with the first request)

  a')  Schedule this cache reload to be run automatically every so often,
       so that the cache is always ready for incoming requests
       (which *will* help with the first request, but introduces an
        overall load on the subagent, even if the MIB isn't being queried)

   b)  Have the (sub)agent load *some* of the information about each row
       (basically the index information, plus anything that comes for free with
       that) rather than all of it.   That should hopefully be faster, but still
       allows the agent to know which rows are valid in the table.

            Then query the rest of the information for a particular row when
      it's actually requested.   That should allow the subagent to respond
      in a more timely fashion.

I don't think that you've said which table framework you are working with,
That latter approach is straighforward enough with the iterator or table_data
helpers - I can give you pointers if necessary.
      I don't know enough about the MfD framework to comment on that style
of code, if that's what you are using.

Dave

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users