1

TLDR: Why is there a pause before the page updates, resulting in a small white gap in the graph?

I recently discovered cubism and was blown away. So I decided my raspberry pi could use some monitoring. I am also new to javascript and all web-related stuff in general, so bear with me.

My own datasource consists of a redis database and webdis which I use to get the data in json format. In redis I store a combination of timestamp and value (timestamp:value) every second, in my example the used physical memory.

So when I query webdis like this:

http://192.168.0.3:7379/zrangebyscore/used_phymem/1382269532/1382269532

I get back this: {"zrangebyscore":["435265536:1382269532"]}

So this part is working great. In another answer here on stackoverflow Mike Bostock explained how Cubism queries for data: Using Other Data Sources for cubism.js. In short there is an initial query for 1440 datapoints (the whole window) and after that only queries for the last 7 datapoints. I logged how Cubism behaves in my code:

http://192.168.0.3:7379/zrangebyscore/used_phymem/1382268969/1382270409 1440 values
http://192.168.0.3:7379/zrangebyscore/used_phymem/1382270398/1382270410 12 values
http://192.168.0.3:7379/zrangebyscore/used_phymem/1382270398/1382270411 13 values
http://192.168.0.3:7379/zrangebyscore/used_phymem/1382270398/1382270412 14 values
http://192.168.0.3:7379/zrangebyscore/used_phymem/1382270398/1382270413 15 values
http://192.168.0.3:7379/zrangebyscore/used_phymem/1382270398/1382270414 16 values
http://192.168.0.3:7379/zrangebyscore/used_phymem/1382270408/1382270415 7 values

As you can see, there is an initial query for 1440 values. But after that there are some queries that I don't understand, before the mentioned queries for 7 datapoints start. Why does cubism query for 12,13,14,15,16 values, all with the same start time?

The result looks like this (notice the gap to the right): request

I cannot figure out why there is that window of missing data...

This is my function to query the data:

function getData(metric) {
return context.metric(function(start, stop, step, callback) {
    var values = [];
    start = +start, stop = +stop;

    d3.json("http://192.168.0.3:7379/zrangebyscore/"+metric+"/"+(start/1000) +"/"+ (stop/1000), function(json_data) {
        entries = json_data.zrangebyscore;
        entries.forEach(function(e) {
            values.push(scale(e.split(":")[0]));
        });
        callback(null, values = values.slice(-context.size()));
    });      
}, name);
}

And this is the rest of the code:

var metrics = [ "used_phymem" ];

var context = cubism.context()
    .serverDelay(10 * 1000)
    .step(1 * 1000)
    .size(1440);

var scale = d3.scale.linear()
    .domain([0, 459505664])
    .range([10, 100]);

d3.select("#demo").selectAll(".axis")
    .data(["top", "bottom"])
    .enter().append("div")
    .attr("class", function(d) { return d + " axis"; })
    .each(function(d) { d3.select(this).call(context.axis().ticks(12).orient(d)); });

d3.select("body").append("div")
    .attr("class", "rule")
    .call(context.rule());

d3.select("body").selectAll(".horizon")
    .data(metrics.map(getData))
    .enter().insert("div", ".bottom")
    .attr("class", "horizon")
    .call(context.horizon()
    .extent([0, 100]));

context.on("focus", function(i) {
  d3.selectAll(".value").style("right", i == null ? null : context.size() - i + "px");
});

UPDATE:

I added an example on jsbin that uses random numbers instead of my json data:

http://jsbin.com/ABoLaya/1/

When the page loads, the graph is full of values (as expected), then for a second nothing happens. After that the graph updates every second, but between the initial data, and the rest of the data is a gap.

Community
  • 1
  • 1
imbaer
  • 554
  • 3
  • 21
  • Did you verify that the data you're getting back is what you would expect? – Lars Kotthoff Oct 19 '13 at 20:50
  • Yes, there is no corresponding gap in the database, and queries _should_ cover that data. The issue with the gap must be related to my sync / async issue. – imbaer Oct 19 '13 at 21:07
  • Not sure what you mean by synchronous. Surely all the requests you make are async? – Lars Kotthoff Oct 19 '13 at 21:43
  • I mean the open call of XMLHttpRequest, the third parameter determines whether or not it should be synchronous or asynchronous. – imbaer Oct 19 '13 at 22:06
  • Right. Nevertheless all your data handling is done in a callback, so I don't see how it would make a difference. – Lars Kotthoff Oct 19 '13 at 22:14
  • Hey, the sync/async is no longer an issue, I rewrote some code and am now using the d3 json function. However the gap in the graph is still there. I updated the question and explained better what is going on. I have no idea why this happens. – imbaer Oct 20 '13 at 12:16
  • Could you put a complete working example somewhere? – Lars Kotthoff Oct 20 '13 at 12:24
  • I can't host it, but I just found out, the issue is not my redis / webdis stuff. I changed the code to use random numbers instead and it shows the same behaviour. I must have messed up somewhere, I just can't figure out where. I updated my post with pastebin data which should reproduce that behaviour I experience. – imbaer Oct 20 '13 at 12:54
  • I added an example on jsbin: http://jsbin.com/oxaKONO/1/. You will see that the graph looks really nice, but after the initial load for a second or so nothing happens. After that the graph updates every second, but between the initial data and the other data is a small gap in the graph. – imbaer Oct 20 '13 at 15:50
  • 1
    It appears that this is because of a delay/clock skew on the server. If I add a client delay of 1 second, it looks fine -- http://jsbin.com/iYuceku/1/edit – Lars Kotthoff Oct 22 '13 at 19:07
  • Nice catch, thank you! That definitely fixed it. Do you want to post this as an answer so I can mark the question as solved? – imbaer Oct 23 '13 at 14:21

1 Answers1

1

The cause of the problem appears to be a delay/clock skew on the server. If you add a client delay of 1 second, everything works fine (see http://jsbin.com/iYuceku/1/edit).

Lars Kotthoff
  • 107,425
  • 16
  • 204
  • 204