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

[Tobias Oetiker]

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

I can shed some light on my thinking behind the graphing library
switches.

libgd -> libart (libart seemd to be the up and coming standard
    graphing library at the time (gnome was using it too). The main
    advantage over libgd was its support for anti-aliased output
    and alpha transparency)

    unfortunately I later found that there were numerical stability
    problems with the library and its development did not advance
    any more, up to the point of it being dropped by gnompe

libart -> cairo/pango - has proven to be the standard way of doing
    graphics at least in the c world (there are other c++
    solutions). The switch from libart to cairo provided for a
    better maintained library and the use of pango helps with
    international font support a lot. It further alignes rrdtool
    with the set of libraries comonly found on linux boxes and
    integrates support for the unix fontconfig font standard.

As for graphing performance, I have done some extensive profiling
in the 1.3 release cycle. The main performance impact seen by some
users stems from pango/fontconfgs font matching and loading code.
On systems with a large number of fonts installed, the subsystem
can spend several seconds pondering this fact. Pango has internal
caching for this but it only works if the process using pango does
not shutdown. RRDtool 1.3 has several tweaks to make sure it
cooperates with pangos caching attempts ... the net result of this
is that if you generate multiple graphs in one the font related
performance impact will only occure for the first graph. There may
also be a pango-version related component to that.

Another major time-sink is the compression of the png file ... this
has not changed over time ... but I have not investigated the
impact of using different compression levels ...

That said, I think both a benchmark and a testing suit for rrdtool
would be a great thing.

Michael Schilli has created a set of tests for his RRDtool::OO
module ... and the RRDs perl bindings also have a very rudimentary
test set included ...

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