[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.


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