[rrd-developers] Bug#419948: librrds-perl: Information about affected platform

[Tobias Oetiker]

Hi All,

I have spent considerable time improving the graph performance in
the latest 1.4.x editions ...

one major cause of slowdown was 'font selection'. Depending on the
number of fonts on your system this can take a long time ...  if
you generate multiple graphs with a single instance of rrdtool (eg
by using it via the language bindings or with the pipe interface)
the fonts will be cached between invocations and the performance
impact occures only once ...

a second source of slowdown is the gzip compression applied to the
png file ... with gzip level 1 graphs would be created much more
quickly ... unfortunately cairo does not provide access to this
setting of libpng..

to recap

a) use 1.4.8

b) use language bindings or the pipe interface

c) create a patch so that rrdtool uses cairo to just fill an image
   buffer and then pass the buffer on to libpng directly for fast
   compression.  The code for this can be found in 1.3.x where this
   was necessary because the graphing library did not provide png
   output capabilities internally.

hth
tobi

Today Sebastian Harl wrote:

> tags 419948 + wontfix
> thanks
>
> This bug had not seen any activity in year. It seems rather unlikely
> that any resources will be spent on this and further tracking it does
> not make sense imho.
>
> Also note that there are some ideas around redesigning RRDtool from the
> ground up -- see https://github.com/oetiker/rrdtool-2.x
>
> On Sun, Mar 21, 2010 at 05:17:16PM +0100, Sebastian Harl wrote:
> > Hi Florian and Carl,
> >
> > (This is a follow-up to Debian bug report #419948 -- see
> > <http://bugs.debian.org/419948> for details.)
> >
> > On Wed, Sep 30, 2009 at 09:54:06PM +0200, Sebastian Harl wrote:
> > > On Mon, Sep 28, 2009 at 10:32:52AM +0200, Florian Schlichting wrote:
> > > > On Thu, Sep 24, 2009 at 06:17:55PM +0200, Sebastian Harl wrote:
> > > > > Okay, so it seems we've got a rather major speed-down in rrdgraph Sarge
> > > > > -> Etch (RRDtool 1.0 -> 1.2) and another one Etch -> Lenny (RRDtool 1.2 ->
> > > > > 1.3). In the former case, RRDtool switched from using libgd to libart
> > > > > for doing the graphing, in the latter case, they switched to libcairo
> > > > > (and libpango). I'm pretty sure, the speed-down is related to that. In
> > > > > the course of the 1.3.x releases some optimizations have been applied
> > > > > which improved the effect a bit but there still is a notable speed-down.
> > > > >
> > > > > Anyway, frankly, I've got no idea what to do about that.
> > > >
> > > > well, I think that's a good explanation. So it's not a "bug", but an
> > > > intentional design decision with not-so-intentional side effects.
> > [?]
> > > > I don't know about upstream's motivation for those switches, but
> > > > perhaps it would be worthwhile to benchmark graphing with the
> > > > different libraries / RRDtool versions and reevaluate their merits in
> > > > that light?
> > >
> > > I'm not sure about the motivations either :-/ Benchmarks would be really
> > > great. Are you willing to take care of that?
> >
> > Does anyone of you happen to have some benchmarks available (or could
> > you rather easily get any)?
> >
> > With this E-mail, I'm also forwarding the bug upstream (this should have
> > happened long ago :-/ ), hoping for some more input / suggestions /
> > further ideas.
> >
> > Cheers,
> > Sebastian
> >
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902