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

[Sebastian Harl]

Hi,

On Sun, Mar 21, 2010 at 05:38:40PM +0100, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > (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.
[…]
> 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.

The original bug reporter reported an increased CPU usage when
generating graphs from munin. I'm not sure if munin simply executes the
rrdtool binary to do so or whether they use librrd directly (or thru a
scripting language wrapper). The caching will only have any effects in
the latter case, I suppose.

Anyway ... cairo also includes a very basic sub-system for rendering
texts (the cairo_*font* and cairo_*text* stuff). It supports left-to-
right texts only and no other "fancy" stuff (e.g., kerning ;-)) but that
should be sufficient for quite a few users of RRDtool. Does anybody
happen to know if/how much performance gain we might expect from using
that interface (and leaving pango out)? Would it be feasible to have
RRDtool support pango *and* that interface (and make that configurable
by a command-line switch)?

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

The problem is that cairo does not provide any interface to change the
PNG compression level (see, e.g., [1]). Currently, cairo seems to use
the zlib default compression level, which is 6 in version 1.2.3.4. In
RRDtool 1.2 this was set to 1. So, this is another source for a speed-
down between RRDtool versions 1.2 and 1.3.

[1] <http://lists.cairographics.org/archives/cairo/2009-February/
     016542.html>

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

Ack.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20100321/ca8b174c/attachment.pgp