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 t...@oetiker.ch ++41 62 775 9902 / sb: -9900 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
