[rrd-developers] rfc: later caching

[Tobias Oetiker]

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 tobi at oetiker.ch ++41 62 775 9902 / sb: -9900