[rrd-users] RRA/RRD tuning

[Tobias Oetiker]

Today Christoph Anton Mitterer wrote:

> Hi Tobi.
>
> Thanks for your replies :)
>
>
> On Sun, 2012-08-12 at 09:07 +0200, Tobias Oetiker wrote:
> > > As far as I understand, less RRAs should mean faster updates, right?
> > yes
> So that also means, from just focusing on the update time (and ignoring
> space and graphing)... the best would be to have _just one_ (very
> detailed) RRA, going with the highest step resolution over the full time
> period.... even if it's 200 years...
>
>
> In other words,... the RRAs are solely intended to do the follwwing
> jobs:
> a) decrease space for periods more back in time where no high precision
> is needed anymore
> This should be the only case when the RRA has less resolution than the
> one with the highes resolution, _but_ goes further back in time

yes

> b) increase graphing time
> This should be only the case for those parts of an less detailed RRA,
> that is in the same time range as the higher detailed.

yes

> As all RRAs always start at the same time range (i.e. now)... it's not
> possible to get just (a).

yes

> Ok... if all that is correct... I think it would make perhaps sense to
> add this somewhere to the documentation, doesn't it?
> At least I couldn't directly read out that information from what I've
> found :)

patches are always welcome ... especially if they help other people
understand how rrdtool works

> > it is smart enoughh ...
> Simply awesome! :D
>
>
>
> > the biggest win for graphing time would be to integrate support for
> > setting the png compression level into rrdtool ... libcairo sets
> > this very high, and thus spends considerable time compressing the
> > resulting png file ... setting the compression level to 1 should
> > give a considerable performance gain ...
> Are there any time comparisons between the different formats (I mean PNG
> vs. SVG, etc.)?

not too my knowledge ... but that should be pretty easy todo :-)

> > I will be glad to integrate your patch
> I just had a small glance on the cairo api... but it doesn't seem as if
> it would export an interface to set the compression level... so that
> would have probably to be implemented there first.

well since modifying cairo is not realy something which would
quickly carry to all the distros, it might be more beneficial to
add png generation ability back into rrdtool and just get a
pixlebuffer from cairo instead of an already compressed png ...
there was such code in rrdtool 1.2 (when it was still based on
libart) ...

looking at cairo docs, it seems that the png output facility is
regarded more as testing fehicle than an actual prduction quality
feature, hence probably the lack of knobs to tune it.

cheers
tobi
>
>
> Thanks,
> Chris.
>

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