finish() changes

[drusenko]

sendBeacon should be called after the cookie is set (right before "this.running = false", instead of right after "this.complete = true") so that we can access the "t" property of the cookie.

Additionally, the "t" property should be passed to the beacon script.

Access to the "t" property is helpful when trying to detect duplicate entries in the beacon script, and prevent recording multiple entries with the same data.

[bluesmoon]

I agree on moving sendBeacon further down, but I'm not sure how useful having t would be. Could you elaborate a little more on why we can't just use the timestamp when the request hits the server to detect a duplicate beacon? It could be that I've misunderstood and you're talking about stopping a duplicate beacon before it's sent, but even then I'm not sure how passing t to the script would help.

[drusenko]

't' essentially identifies a cookie, since it's only set when the cookie is updated. On the server, I'm creating a table with a primary key (user_id, t) to prevent storing the same test over and over again, since the beacon is called on page load regardless of whether the results are fresh or not.

Alternatively, you could just not call the beacon if the results are cached, but it seems like probably something you should let the beacon script decide.

Hope this makes sense! Let me know if you'd like any further clarification.

[bluesmoon]

ok, I understand and it makes sense.

remember that this t value is only for the bandwidth test and not for the page load time test, so you would still need to send the beacon even if the results are cached. Also, if you do it the way I do, I store the bandwidth for every beacon, even if it was cached. this works well if you're distributing your back end load to multiple boxes and want all beacons to be self-contained.

I'll make the change anyway.

[bluesmoon]

call sendBeacon() after setting cookie, and pass bandwidth time in the beacon. Closed by 09d17921b380a9c810b7c1407ab4b004e6af5645

[bluesmoon]

I should mention one caveat though. This time is measured on the user's computer, which might be very different from your server time. It may even be in the wrong century. Users have funny clocks.

[drusenko]

awesome! in our case, we're only storing the page load time/bandwidth once, and the time is useful as an ID for when the bandwidth data is refreshed (regardless of what the actual time is...)

thanks for the quick response!

[bluesmoon]

you using it at weebly?

[drusenko]

playing around with it, may try to use the bandwidth/latency measurements with a subset of users...