My main worry was not about /dev/null being slow (or about the I/O in
general), it's the CPU time that it takes the server to actually render the
graph a second time.  I'm looking into pushing changes into rrdtool right
now.  And definitely the idea here is not to penalize the graph creation at
all.  It should be as fast or faster than it already is. :)

 

I sent a message to the rrd-users list and got this reply, which I thought
was interesting:

 

Matthew Chambers wrote:

> Is there a way to tell rrdtool to generate a graph image (including 

> the

> legend) with exactly the dimensions provided to it on the command line?

> I've done a hackish workaround which involves running rrdtool twice, 

> so that the extra width and height of the legend can be detected and 

> then compensated for, but that is quite suboptimal and not very scalable.

> Otherwise, is there a way to get more control over how the legend is 

> formatted?  My hackish workaround doesn't always work because if the 

> legend format changes (i.e. goes from one line to two lines) when the 

> width is adjusted, the adjustments are invalid.

 

I've had good luck with calculating the correct width and height to pass to
rrdtool based on the the desired size of the finished image and the number
of lines the legend is likely to take up.

 

Basically, you can figure out the amount to take off the width pretty easily
(I use 97 pixels).  If your legend lines are a consistent length you can
figure out the width at which they will wrap, then do something

like:

 

$w = $request['w'] - 97;

 

$multiline = $request['w'] < 500;

 

$dh = $multiline ? 169 : 141;

 

$h = $request['h'] - $dh;

 

HTH,

 

Dan

 

In the end though, I don't think it's feasible to really predict what the
legend is going to do from the PHP.  The best place to do that is in
rrdtool.  I hope Tobi Oetiker is amenable to such a change (I'm thinking of
two new options, one like --awidth for actual image width and --aheight for
actual image height).

 

-Matt

 

  _____  

From: Richard Grevis [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 08, 2007 10:44 AM
To: [EMAIL PROTECTED]
Subject: RE: [Ganglia-developers] Web frontend graph sizes

 

Doh,

 

Sorry, I misread your mail. Ignore '-' stuff, but what I said - "don't worry
about /dev/null" remains true.

Anyway, determining graph size probably needs a fair chunk of rendering
effort.

 

The best solution would be push a few changes into rrdtool.

 

I do other things as well for the cluster view and the little host graphs.
Becase of another our local mods,

the graphs do not end at "now", they  have represent any previous time
period. So how do you determine

the load colour they should have? I do a seperate rrdtool call with a gprint
of the maximum value seen in the period,

and use this to colour the graph. The colour (and graph ordering) also
becomes based on the full period

and not the final moment. For all of that, in the case where is the time
period endpoint is now,

the standard way ganglia behave is actually the one I prefer.

 

I also use all the maximums gathered above to set identical scales on the
graphs as finally rendered.

 

And yes, I have managed to make the rendering of the cluster view too slow.

 

regards,

Richard 

 

This may not get through to the mailing list - i've been changing mail
addresses. if so, feel free to forward it.

 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to