[rrd-developers] rfc: later caching

[kevin brintnall]

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

-- 
 kevin brintnall =~ /kbrint at rufus.net/