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 [EMAIL PROTECTED] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers