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 ... > _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
