Hi guys,

I can't find documentation about ajax requests data points collected by BuckyClient.
From the README page:

The data collected will look something like this for a GET request to api.hubapi.com/automation/v2/workflows:

contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get: "656.794|ms"
contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get.2xx: "1|c"
contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get.200: "1|c"
contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get.headers: "436.737|ms"
contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get.receiving: "0.182|ms"
contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get.sending: "0.059|ms"
contacts.web.prod.requests.api.hubapi.automation.v2.workflows.get.waiting: "206.035|ms"

but what's the meaning of each of these datapoint?

Thanks
Paolo

Hello!

As my name says I am new here. I am not a dev guy.To be precise I have got a QA background for performance. I am interested in bucky and want to try it out. But I am not able to download the client. The page https://codeload.github.com/HubSpot/BuckyClient/zip/v0.2.4 loads up and show a message 'Not found'. Could you guys please guide me?

Thanks

https://github.com/HubSpot/BuckyClient/blob/master/bucky.js#L486

This issue is more to get your thoughts on this as a feature.

We are seeing very data coming into our InfluxDB collector that is so noisy as to make it near impossible to get actionable metrics. For instance, domInteractive on a certain page has a mean of 8329 with a standard deviation of 13898. (sample size=62000+). Which is due to some very large long-tail response times - but even throwing out everything above the 90th percentile, the stddev is still at 6188.

They way these are collected as offsets from navigationStart is good, but it seems to me the variation in each of these measurements from that point is cumulative. In other words, domInteractive is more variable because it includes all the potential variations in caching, DNS lookups, response times, etc.

It might be helpful to collect offsets between each timing event and it's predecessor as well. For instance, performance.timing.domInteractive - performance.timing.domLoading would be an interesting handle on blocking CSS or JS issues.

It may be something that could be left to the user as a config option.

Is it possible to have the latest release on npm? Thanks in advance

Hi guys,

Awesome job on bucky btw.
But I just wanna ask if there's a way for us to send custom metrics since currently bucky sends raw metrics and if we wanted to have precomputed ones like "TotalPageLoadTime" and have it sent to OpenTSDB

e.g.
Total Page Load Time = performance.timing.loadEventEnd – performance.timing.navigationStart
connectTime = perfData.responseEnd - perfData.requestStart

Best regards

The requests.transformations.disable method is using the variables in the for loop in the wrong order:

https://github.com/HubSpot/BuckyClient/blob/master/bucky.coffee#L408

It should most probably read:

for i, val of @enabled

Followed simple instructions configuring the BuckyClient using Browserify and it keep failing on send with the

time = process.hrtime() - throws Uncaught TypeError: process.hrtime is not a function

message.

As I see - the browserify shim for the "process" module is really not including this method. So I assume there has to be some additional steps to get it up and running in browser?

Hi,
Do you have plan to support IE8.
Thank you.

There have been a number of fixes since the last npm version release. It would be great to have the npm package updated so these can be used.

Hi,
i think that sendPagePerformance method is called too soon in process.

Bucky parse window.performance.timing on DOMContentLoaded event (from document) (code), but at this time some fields (domComplete, loadEventStart, loadEventEnd) are not filled.

• I tried to bind load event (from window) but event fired too quickly and loadEventEnd is empty
• i tried to add setTimeout, it works but so crappy

I think that is more smart to call sendPagePerformance just before first post to server.

What do you think ?

They are candidate specs, but they've landed in Chrome, so I'd like to align Bucky with the new specs:

http://www.w3.org/TR/performance-timeline/
http://www.w3.org/TR/resource-timing/
http://www.w3.org/TR/user-timing/

It's very exciting because it means A. we have access to the timing data of everything on the page, and B. we have a standard (if cumbersome) API to standardize how manual timing is done.

I don't believe there is an event fired when a new timing is added to performance.getEntries(), so my guess is that the best we can do is create a method which will push all new performance entries to the server. We could run that method periodically to pickup the new entries.

In browsers which support this, we might be able to eliminate the timing aspects of the XMLHttpRequest hook. The new API is pretty protective about leaking information about cross origin requests, so it may not be an adequate replacement for those requests.

Currently, BuckyClient has 2 major issues:

• Don't handle unload event, so we might lost tracking data when users click on another link.
• Don't support navigator.sendBeacon API yet. It will support async ajax when users leave the current page (unload event) and also make sure that the tracking data is sent.

If it's ok, I will add a PR.

Hi,
Server setup and health-check are OK but send Cannot GET /bucky/v1/send

./start.js
Loading Config
Loading App
Loading app Module ./modules/trustProxy
Loading app Module ./modules/auth
Loading app Module ./modules/collectors
Loading collectors: ./modules/collectionLogger, ./modules/statsd
./modules/trustProxy Ready
./modules/auth Ready
Collector ./modules/collectionLogger ready
Collector ./modules/statsd ready
./modules/collectors Ready
Binding Routes at /bucky
Server listening on port 5999 in development mode

The current code to identify on which environment the application is running among other things is deferred by the existence of a module.
This is not necessarily true, especially if you use a packaging system like webpack, which uses modules on the client side.
Are there any plans to use another indicator?

File reference

Refering to the line 5 in bucky.js

isServer = (typeof module !== "undefined" && module !== null) && !(typeof window !== "undefined" && window !== null ? window.module : void 0);

As I see from the code
https://github.com/HubSpot/BuckyClient/blob/master/bucky.coffee#L369
Bucky will ignore all the calls to sendPagePerformance after it is done it once on initial load.

Is it just engine performance API that prevents from collecting the data during just Ajax interactions?

I don't really understand the point of configuring the call like

Backbone.history.on 'route', (router, route) ->
   # Will only send on the initial page load:
   Bucky.sendPagePerformance("some.location.page.#{ route }")

if it is not going to send anything anyway because there was no full page request in SPA.

SPA often have bottlenecks on some specific subviews due to non-optimal implementation of DOM updates etc... So in general monitoring for that would be perfect thing (again, if it is something that can be supported by using standard APIs)

boomerang has been tested on thousands of websites (and over a trillion beacons so far) and has many workarounds for browser bugs that affect performance measurement. It also has plugins to measure many other useful metrics. Using boomerang as the front end would gain advantage of many years of work that I and other boomerang contributors have put into it.

boomerang is available under the BSD license from https://github.com/lognormal/boomerang/

It seems the coffee script conversion to JS introduces a bug for the buildPath function:

• https://github.com/HubSpot/BuckyClient/blob/master/bucky.coffee#L252
• https://github.com/HubSpot/BuckyClient/blob/master/bucky.js#L235

There is no return in the JS version.

It would be interesting to support logging memory used after x minutes of the page being open.

a.b.c:662.785|[email protected]
Should be a.b.c:662.785|ms|@0.5 (missing | before @).

Refs https://github.com/etsy/statsd/blob/master/docs/metric_types.md

Hi,
options passed in DOM isn't merged with internal options.

A workaround:
https://github.com/HubSpot/BuckyClient/blob/master/bucky.js#L84

options = extend({}, defaults, tagOptions);

to

options = extend({}, tagOptions, defaults);

Thanks

while trying to collect the stats, i am getting this error:

Collecting example.com.page.navigationStart, example.com.page.fetchStart, example.com.page.domainLookupStart, example.com.page.domainLookupEnd, example.com.page.connectStart, example.com.page.connectEnd, example.com.page.requestStart, example.com.page.responseStart, example.com.page.responseEnd, example.com.page.domLoading, example.com.page.domInteractive, example.com.page.domContentLoadedEventStart, example.com.page.toJSON for ::ffff:192.168.0.1
Unparsable row: NaN|ms
TypeError: Cannot read property '0' of undefined
at Client.write (/home/site/BuckyServer/lib/opentsdb.coffee:25:47)
at next.send (/home/site/BuckyServer/modules/openTSDB.coffee:14:25)
at /home/site/BuckyServer/modules/collectors.coffee:22:25
at callbacks (/home/site/BuckyServer/node_modules/express/lib/router/index.js:161:37)
at next.send (/home/site/BuckyServer/modules/auth.coffee:7:16)
at callbacks (/home/site/BuckyServer/node_modules/express/lib/router/index.js:161:37)
at IncomingMessage. (/home/site/BuckyServer/server.coffee:58:14)
at emitNone (events.js:67:13)
at IncomingMessage.emit (events.js:166:7)
at endReadableNT (_stream_readable.js:905:12)
at doNTCallback2 (node.js:441:9)
at process._tickCallback (node.js:355:17)

Hi,

today I managed to get Bucky working with a StatsD and Graphite backend. The setup was quite easy, the only thing that was a bit counterintuitive was the fact that there's no BuckyServer module to connect to a Graphite server directly but you have to use StatsD as an intermediate service. The documentation says

Next, you'll want to install statsd (...)

which I interpreted as "you can use StatsD but it's also possible to connect to Graphite directly".

In BuckyClient I tried out the example code to track Backbone history event changes from your documentation. I noticed that no performance data were sent when navigating between pages so I debugged the Bucky code and found out that it had to do with the variable sentPerformanceData being true all the time. I understand that it's set to true after the window.performance information have been sent to the backend once. This raised the question why would you call the function Bucky.sendPagePerformance() manually when it won't send any data after the initial page load?. The Backbone history events don't trigger a page reload when you're using a hash navigation so no new performance information are available through the window object. Am I'm getting it wrong?