[rrd-developers] implementing portable format

[Sfiligoi Igor]

Hi Dan and Florian.

Thanks for the comments, but why do you think the RRD is much bigger
than the graph?
Here is what I have today:
[0906] ls -l Status_Attribute_Running.rrd
-rw-rw-r--  1 gfactory gfactory 58408 Nov  3 09:05
Status_Attribute_Running.rrd
[0906] ls -l Running.hour.large.png
-rw-rw-r--  1 gfactory gfactory 18085 Nov  3 09:00 Running.hour.large.png

As you can see, the file sizes are quite comparable.
(BTW: xport would probably return a file that is bigger than the
original RRD file for any significant subset of data)

Furthermore, the network bandwidth is not a major problem; I am more
limited in CPU power then network bandwidth.

Regarding the complexity of implementation, sure, getting the extraction
of information out of the RRD information will be quite a task at first
pass.
But once you have it, it is not harder than what you have today in C;
somebody just needs to do it once ;) Then it becomes a standard library.

Finally, the reason I want client side code is to minimize the security
risks of the Web server. The smaller amount of code I have to run there,
the more comfortable I feel. Buffer overflows, logic errors and DoS
incidents are just too frequent for my taste.
A static Web server is a necessity, everything else is not.

Cheers,
  Igor


Dan Cech wrote:
> Sfiligoi Igor wrote:
>> Moreover, I don't want to allow active CGI scripts on my Web server;
>> I would just like to export the RRD files.
>>
>> The ideal scenario would see a Web browser applet that gets the user
>> input, fetches the needed RRD files and plots the graphs for the browser.
> 
> This doesn't make sense to me.  You're talking about sending a huge
> amount of data to the client vs generating the graph on the server
> (where you have the data already available) and just sending the graph.
> 
> Even if you want to generate the image itself client-side it would still
> make more sense to send only the source data required to the client.
> 
> Dan
> 

Florian Forster wrote:
> Hi Igor,
>
> On Mon, Nov 03, 2008 at 10:35:54AM -0600, Sfiligoi Igor wrote:
>> Maybe I was not clear what was the use case: I have a server with
>> O(10000) RRDs that are updated ~ once a minute.
>
> I have O(2^n) RRD files (for an arbitrary constant `n'). *scnr*
>
>> Moreover, I don't want to allow active CGI scripts on my Web server; I
>> would just like to export the RRD files.
>
> Parsing and processing the binary data on the user side will be hard and
> tedious. Implementing a layer that parses the floating point cookie and
> translates values accordingly surely isn't the most complex part of
> that..
>
> Please don't get me wrong, I'm all for a platform/architecture
> independent storage format. I just think that with such a huge project
> in front of you, this will be the least of your problems..
>
> Regards,
> -octo

Tobias Oetiker wrote:
>> PS: Just in perspective; I expect
>> O(10k) RRD files updated once a minute
>> while the typical read access would be
>> O(10) files every few minutes. (O(1) concurrent users)
>
> exactly the use-case where you have an rpc service on the webserver
> which can run rrd fetch (or xport) ... on the server ... but if you
> insist on not haveing such a service, then ... I guess you have to
> take the long route and suffer ...
>