Re: Bug#419948: Bug#419948: librrds-perl: Information about affected platform

Hi Sebastian,

Yesterday Sebastian Harl wrote:

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

yes, also munin as fahr as I know pre-generates all the graphs in
an mrtg-like fashion, so it will suffer a lot of it takes more
resources to generate a graph

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

as fahr as I remember from my preformance analysis, it was
fontconfig which took a long time identifying the font to use and
pango using its caching working around the problem ...

I know that another user with a similar problem saw massive
performance gains by reducing the number of fonts available ...
this might be done with a local font config file I think.

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

you are right, I remember searching for a knob to tweak that ...
that would be a quick win

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

cheers
tobi
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900