We have a host about 320ms from our observium node (yes.. The other side of the planet).

Doing a full poll circa 650-700ms (including mac and bgp tables... Its a IOS-XR ASR9K ..). Adjusting the Cr/max-reps did increase speeds, and caused several nasty snmpd explosions on the chassis.

As a exercise in interest I spun up a VM much closer to the host, unpacked /opt/observium/mibs etc and configured snmp on that remote host.

Then did this

root@obs1:/opt/observium# diff -c includes/snmp.inc.php.orig includes/snmp.inc.php

*** includes/snmp.inc.php.orig 2014-07-23 17:43:53.720274321 +0930

--- includes/snmp.inc.php 2014-07-23 17:56:23.092286235 +0930

***************

*** 333,338 ****

--- 333,345 ----

// Add the OID(s) to the strong

$cmd .= " ".$oids;

+ if( $device['hostname'] == 'faraway.router.com' ){

+ $cmd = "ssh -i ~x/x.pem x@remote-poller-node -C " . escapeshellarg($cmd) ;

+ }

This was interesting, but the ssh establishment phase for each snmp execution was a lot of overhead.. So I also did this

root@obs1:/opt/observium# cat ~/.ssh/config

Host remote-poller-node

# HostName machine1.example.org

ControlPath ~/.ssh/controlmasters/%r@%h:%p

ControlMaster auto

ControlPersist 10m

This means that a ssh 'master instance' was setup at the start of the poll, and hangs around in the background between executions of various snmpcmd's during the poll.

Full poll went from 650-700ms -> ~170ms

Thought this might be of interest to some people.

Cheers,

Peter