Today kevin brintnall wrote: > > > I thought we'd do it in stages: > > > > > > (1) Process the update string twice. Once when updatev received from the > > > client (update in-memory copy). Once when we call rrd_update_r() with > > > the update string. > > > > > > - minimal changes to the current rrdcached code/data structures > > > - CPU overhead minimal, still large delayed IO benefit of rrdcached > > > - easiest change that gives updatev support > > > > > > (2) Process the update string once. Cache the computed results, and write > > > them out to the RRD after delay. > > > > > > - requires we re-think rrd_update_r() or create a function to pass > > > pre-computed values into the RRD > > > > > > I'm guessing (1) will be significantly easier than (2), and provide almost > > > the same functionality (if slightly less efficiently).. I think staging > > > it like this would make the most sense. > > > > do you see a lot of 're-use' of stuff from (1) in (2) ? Or what is > > the 'sense' in staging the process, given it is done in the safety > > of trunk anyway. > > Maintaining an in-memory copy of the header will be essentially the same > for (1) and (2). Therefore, we should have full UPDATEV support after (1) > without having to drastically change the internals of the daemon or modify > the API to allow pre-computed writes and the associated header updates. > > At that point, we can decide whether re-working the daemon->file part is > worth it. If so, we do (2).
I see you have it all mapped out :-) are you still looking into the auth stuff ? cheers tobi > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
