[rtg] Traffic is wrapping

[bill fumerola]

On Tue, Apr 08, 2008 at 03:59:13PM -0600, Leech, Jonathan wrote:
> JRTG has the same limitation, as it is single-threaded at the device
> level as well, but with less detrimental effect. First, the database
> insertion is seperated from the polling via a buffer, with a fixed and
> configurable number of inserter threads. This allows the polling to
> proceed faster than would otherwise be possible. It also allows for
> pausing, reconnecting, and restarting database inserts, or even changing
> the database instance being written to.

the sqlbuf code does everything above except changing the database. it
uses the max packet the db will accept (uses a mysql constant).

> Second, JRTG polls multiple targets at a time via a single SNMP get.
> This drastically reduces the additive latency issue, and is a lot nicer
> to any firewalls that happen to be in between the poller and the target.
> Less traffic on the network = less dropped packets, fewer retries, and a
> faster polling cycle.

yes, this is certainly something [y]rtg both could use.

> So at the end of a polling cycle, JRTG is still polling the stragglers,
> and not fully utilizing its poller threads, but it finishes them much
> faster, and can effectively use that time to write records to the
> database.

the flusher thread in yrtg more or less flushes as it gets data.

multiple flusher threads would be nice. i didn't do it in yrtg because
in my case i was always connecting to a single database and the raid
took care. one thread or three threads, the array processed things the
same. given database clustering or code that turn a mysql client connection
into a distribution of multiple databases, it would have been better to
use a pool of threads for database inserts.

it'd also be nicer if rtg supported multiple databases and sending
different results to each.

the java VM overhead compared to the overhead of running multiple instances
of rtg probably are comparable.

-- bill