Re: RES: [Perfparse-users] Prune performance fata on graph presentation

[Yves <yme...@pe...>]

>> I will probably work on that soon, but when you have
>> something like 1500 points in one day, what point will you take ?
>> When you draw a graph for a long period, you don't care about
>> details. What details to remove ? Do you want to see average
>> values for every day in one month ? The max per day ? The min
>> ? Draw them all ? Draw other values (std deviation... ) ?
>
> As a physicist by formation, I really understand your worries. But IMO
> the solutions are:
>
> * For a monthly graphic, pick up the max, medium and min values for the
> day and plot them.
> * For a yearly graphic, do the same for monthly values.

I had the same ideas. Good that we have the same opinion :)

[...]

> Yes, you don't need too much precision (and thus my suggestion to use
> mean values) but you do need graphics that do look good. Don't take me
> wrong, but MRTG has been doing this from years! I think it won't byte i=
f
> we take a look into MRTG's solutions to make PerfParse code better and
> meet end user expectations.

mrtg and rrdtool :)
Yes, of course. It is not possible to make some elegant CGI with mrtg or =
rrdtool in
perfparse and that's the reason why we are reinventing the wheel :)
Well, it takes time to reinvent the wheel, and before that, Ben works on =
the database
schema.
Then, with summary data, you will have the values you want in the databas=
e, and just
have to plot them. When the new database is ready, this will be easy to d=
o :)


>
>> > *	Allow export of metrics to CSV files, so they can be treated
>> > outside of PerfParse using software like LabPlot or OpenOffice
>> > Spreadsheet.
>>
>> I suggest a tool that does it on the command line. And if
>> wanted, front-ends of course :)
>
> I think it's better integrate this in PerfParse front-end from the
> beginning. IMO, PerfParse's public are not only geeks but also their
> managers. ;)

I will explain my point of view to make things clear. I begin with the co=
nclusion : of
course, we integrate this as soon as possible in a front-end :)
In fact, we will do a lot of code :
- take the data from many possible sources (mysql database, other databas=
es, perfparsed
and maybe other sources)
- draw a graph or make CSV documents
- ...
If we put everything in a graphic tool, we have problems. For example, pe=
rfchart.cgi can
draw only from a mysql source. You have to rewrite it if you take another=
 database or if
you want to draw other values.
So we need a library that does a lot of things, but not the presentation.
Then we make a command line tool that use the library. For tests and geek=
 users.
And then, (this is the conclusion), as soon as possible, we make the fron=
t-end for real
users and managers.
When somebody else (like Flo) wants to write another front-end, he writes=
 the front-end
only, not everything :)
I hope I was not too boring with my explanations :)

Yves


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- Perfparse   - http://perfparse.sf.net/                           -