[rrd-developers] implementing portable format
Tobias Oetiker
tobi at oetiker.ch
Mon Nov 3 20:47:34 CET 2008
Hi Kevin,
Yesterday kevin brintnall wrote:
> > yes this certainly makes sense, does rrd_update with multiple
> > arguments use the batch mode ?
>
> RRD update with multiple arguments just passes one large line through to
> the daemon.
>
> rrdtool update x.rrd V1 V2 V3
> rrdtool update y.rrd V4 V5
>
> ... causes protocol
>
> C: UPDATE x.rrd V1 V2 V3
> S: 0 Enqueued 3 updates
> C: UPDATE y.rrd V4 V5
> S: 0 Enqueued 2 updates
ah ok ...
> This means that each RRD requires one small read() and one small write()
> on both client and server. This causes a lot of sys calls... that's what
> batch mode is designed to get around.
except that normally multi argument updates are with 100s of
updates, so that should not matter much ...
> The only approach I can see with the existing API is to always return
> success when the client is in batch mode.
>
> I think the right approach is:
>
> * global state in rrd_client.c to indicate whether we're in BATCH mode
> (maintained in the same places as sd and sh)
> * response_read() fakes success code if(batch_mode)
> * request() avoid fflush() if (batch_mode)
> * rrdc_batch_{stop,start} to start/stop batch mode in client
>
> Then, we could expose rrdc_batch_start() and rrdc_batch_stop() via the C
> API and various bindings..
this sounds fine, except that I wonder if it is necessary at all.
If someone wants to write 'for the daemon' they can easily talk to
to the daemon directly.
cheers
tobi
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900
More information about the rrd-developers
mailing list