Speed of SNMP - SNMP

This is a discussion on Speed of SNMP - SNMP ; Hi Folks, I'm using Net::SNMP to retrieve data from NetApp Filers from a perl script, although I'm concerned about the amount of time it's taking... Executing get_entries() to grab 3 columns of data (two short strings and an integer) from ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Speed of SNMP

  1. Speed of SNMP

    Hi Folks,

    I'm using Net::SNMP to retrieve data from NetApp Filers from a perl
    script, although I'm concerned about the amount of time it's taking...

    Executing get_entries() to grab 3 columns of data (two short strings
    and an integer) from a table which has 141 rows takes over 30 seconds
    before returning. Is SNMP really this slow, or should I be bugging a
    Perl group? Any suggestions as to how to speed things up...?

    I'm using SNMPv1 btw, which appears to be the only version supported by
    the filers...

    Thanks in advance,

    Andy


  2. Re: Speed of SNMP

    On 27 Jul 2005 03:58:54 -0700, Andy wrote:
    > Hi Folks,
    >
    > I'm using Net::SNMP to retrieve data from NetApp Filers from a perl
    > script, although I'm concerned about the amount of time it's taking...


    Net::SNMP is (was) the slowest in the comparison in:
    http://groups.google.dk/group/comp.l...8a27eda8d16eda
    or if link defectiv:
    Message-ID:

    Perl with (now) net-snmp would help on the server-side.
    >
    > Executing get_entries() to grab 3 columns of data (two short strings
    > and an integer) from a table which has 141 rows takes over 30 seconds
    > before returning. Is SNMP really this slow, or should I be bugging a
    > Perl group? Any suggestions as to how to speed things up...?


    Take a dump of the packet exchange and see what the responcetime is.
    Is the roundtrip time to the machine large?
    On some SNMP agents some OIDs require much work to fetch (bad impl)
    OIDs in the system tree are sometimes faster. What is the responcetime?

    >
    > I'm using SNMPv1 btw, which appears to be the only version supported by
    > the filers...

    So getbulk is no option.
    /hjj

  3. Re: Speed of SNMP

    Hi Hans,

    > Perl with (now) net-snmp would help on the server-side.


    What do you mean by this? (It sounds like you're suggesting putting
    perl and net-snmp on the filer!)

    > Take a dump of the packet exchange and see what the responcetime is.
    > Is the roundtrip time to the machine large?
    > On some SNMP agents some OIDs require much work to fetch (bad impl)
    > OIDs in the system tree are sometimes faster. What is the responcetime?


    Right, using ethereal to sniff the SNMP traffic, and the net-snmp tools
    to request data... a single GET-REQUEST is followed by a GET-RESPONSE
    within about 2ms, which is fine...

    However, if I try and retrieve a table of snapshot information,
    GETNEXT-RESPONSEs become slower and slower - starting at about 2ms
    after the request and increasing linearly to 150ms after around 500
    request/responses.

    I also did an snmpwalk on the standard OID (.1.3.6.1.2.1) - this data
    was belted back with a whopping 0.2ms delay between request and
    response. This suggests that your assumption regarding a poor
    implementation of non-standard OIDs was correct, true? Or is there
    anything I can do to imporve performance?

    The ping time from my workstation to the filer is a constant '<1ms'.

    > So getbulk is no option.


    Nope


    Thanks for your assistance,

    Andy


  4. Re: Speed of SNMP

    On 28 Jul 2005 02:40:09 -0700, Andy wrote:
    >
    >> Perl with (now) net-snmp would help on the server-side.

    >
    > What do you mean by this? (It sounds like you're suggesting putting
    > perl and net-snmp on the filer!)
    >

    Oh no, I was thinking in SNMP context, ie server==sending SNMP request.

    > I also did an snmpwalk on the standard OID (.1.3.6.1.2.1) - this data
    > was belted back with a whopping 0.2ms delay between request and
    > response. This suggests that your assumption regarding a poor
    > implementation of non-standard OIDs was correct, true?


    Yes, time to give vendor a call.
    Is the filer's performance hampered by the SNMP requests?
    Can you live with data collection taking long time?

    > Or is there
    > anything I can do to imporve performance?

    Is the information available by other channels, ie telnet, ssh, http?
    Parsing this output may be faster.
    /hjj

  5. Re: Speed of SNMP

    > Yes, time to give vendor a call.
    > Is the filer's performance hampered by the SNMP requests?
    > Can you live with data collection taking long time?


    Yeh, the filer's CPU usage goes right up around 80%-90%, sometimes
    peaking at 100%... which is bad being sustained for as long as it is.
    Unfortunatly in this sceanrio waiting 10 minutes to collect all the
    required data isn't really acceptable.

    > Is the information available by other channels, ie telnet, ssh, http?
    > Parsing this output may be faster


    I was originally using RSH to retrieve the data (information about
    filesystem snapshots to be precise) and this was super-quick. I need to
    know the complete date a snapshot was generated, but the RSH command
    failed to provide this (just day, month and time)... which is pretty
    bad for a product sold on the premise that backups can be kept for
    years and years!!! So SNMP is the only way I can get the data I need,
    but it looks like thats not feasable now (

    Will try contacting the vendor... wish me luck!

    Thanks again for all your help,

    Andy


  6. Re: Speed of SNMP

    Andy wrote:

    > Or is there anything I can do to imporve performance?


    I hope you are reading the table in row-by-row order (that is all
    columns of a row in a single request) since this reduced the total
    number of interactions and might help the poor agent implementation.

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

+ Reply to Thread