Re: about [rrdtool-1.x] Fetch callback (#502)
Tobias Oetiker <[email protected]> Fri, 13 Jun 2014 15:00:39 +0200 (CEST)
| Newsgroups | gmane.comp.db.rrdtool.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Peter, Today Peter Childs wrote: > > Reading the comments, and the edit to src/rrd_graph.c > > 968 + // remember that we already got this one > 969 + g_hash_table_insert(im->rrd_map,gdes_fetch_key(im->gdes[i]),GINT_TO_POINTER(i)); > > I have noted when I tried to build a custom backend using > rrdcached protocol that when drawing a graph it appeared to a > little inefficient. > > For example > If I had a RRD with DS(s) of inOct, outOct, inErrs, outErrs and then used 'graph' to generate a single graph with all those DS's from the same RRD I would see 4 FETCH operations via rrdcached. > > Since the fetch does not specify the DS required, all the > datasources in the RRD need to be returned. This probably isn't > a problem for simple RRD files, but for example if you have 12 > metrics, and each metric has a 'cost' to 'get', and you only > really need two for your graph, you need to fetch them all anyway > (or in my example, you need to fetch them all, then remangle them > into the appropriate structures, then return them ..) > > My question is -- does this change to the rrd_graph data_fetch() > mean that I will not see multiple fetch operations ? exactly ... as you can see this is only the 'other half' of the change. the first half had been therer for the last year or so, but when putting it in I must have gotten distracted ... :-( the fast that fetch does not get to know which ds is required is a bit of a problem in the api, but since you can put extra information after the cb// key when calling the callback, you could use this to specify what you want and pass the information along in this way ... due to the way the metrics are stored on disk, the assumption is that it is quicker to fetch the lat than to split them up while fetching ... the 'only fetch once' thing has been in rrdtool before, but we did a linear search which affected graphs containing tousands of DEF lines rather negatively. cheers tobi > > (I guess I should just go and test it ...) > > :) > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch [email protected] +41 62 775 9902