Instrument add-on for performance about activity-stream HOT 8 CLOSED

Sample Measurements:

• Number of db queries per page load
• Time to fully load a page (page load latency)
• Request/response cycle response time

from activity-stream.

There are some notifications we need from UI, at least for responsiveness and some latency measurements

from activity-stream.

@oyiptong - need clarification on your points

1. Number of db queries per page load
   Does this mean any API call to PlacesProvider? For example, there's a delete query, do we count that? Do you care for individual query times?
2. Time to fully load a page (page load latency)
   I believe time diff between page "open" and "pageshow" (or "ready") tab invents gives this difference.
   (@emtwo, could you verify that statement. If not I will run some tests to see when tab events fire, but if you already had done it, perhaps you can share the results)
   We could introduce an extra notification from content if and when it knows that page is fully loaded.
   I suspect this function would be a good candidate to notify from: https://github.com/mozilla/activity-streams/blob/master/content-src/components/Base/Base.js#L14
3. Request/response cycle response time
   Do you mean specifically PlacesProvider calls, as they seem to be the only API doing request/response cycle. Again, do we care for individual queries, or just the average?

from activity-stream.

@emtwo
TabTracker seems to be a good candidate to park telemetry data.
Do you have any objections against parking performance data next to tab sessions?
For example, it may have a method
logQueryTime: function(tab, query, time) {
...
}

May this work?

from activity-stream.

Does this mean any API call to PlacesProvider? For example, there's a delete query, do we count that? Do you care for individual query times?

The first number we want is the number of DB queries called for each page load. This is useful so we have a number to diminish if we need to.

We can also capture individual query times so we know which to optimize.

We can perhaps logs those query times as a debug statement. (we might need to relax the linter to do so).
A console output toggle-able by a pref would probably make sense here.
It might be interesting to know what the number of queries are for different load reasons.

I don't see much value in sending the # of DB queries as a telemetry ping, because they won't change much. The response times might be interesting to send/analyze, but we won't have the correct data processing at the moment given our timeline yet.

Time to fully load a page (page load latency)

Browser events won't be enough. We'll need the react/redux front-end to tell us when the page is "fully loaded". By "fully loaded", I mean that the page is ready to be used by the user. My intuition tells me that react/redux adds some latency. The browser events will just tell us that either: the document's DOM has loaded, but as we know, it initially loads a minimal DOM, then redux/react take over and add DOM elements dynamically.

We'll need content to send a message to chrome when it thinks it's done. I would say, it happens when all data has been received, DOM elements created and rendered on screen, with the page ready to listen to user input. Let's for now leave image loading out of the equation.

This data might be easily stored in our data back-end as it would just be a column.

Request/response cycle response time
Do you mean specifically PlacesProvider calls, as they seem to be the only API doing > request/response cycle. Again, do we care for individual queries, or just the average?

If we have individual query timings, granular information for this is probably not useful.
This could be just an experiment (not code), just to see if message passing latency is even worth keeping track of.

from activity-stream.

TabTracker seems to be a good candidate to park telemetry data.
Do you have any objections against parking performance data next to tab sessions?
For example, it may have a method
logQueryTime: function(tab, query, time) {
...
}

May this work?

I agree that Tab Tracker may be a good place to park this data. Keep in mind we want to keep most of this data separate from what we'll send out to our telemetry servers. For now, we'll print out most of it, preferably under a pref... "debug" mode perhaps.

from activity-stream.

@mzhilyaev I'm not keeping track of load latency so you can go ahead and work on that. I think it's fine for now to collect the data in TabTracker, but I'm not sure where we expect it to go next if it won't be sent to Telemetry servers, @oyiptong?

Do we not want to send perf data at all? or do we want to send it as a separate ping?

from activity-stream.

For now, logging to the console is fine.
We'll figure out what we want to send and how next.

There is value tracking the performance from a development standpoint. We might want more time on the server data back-end to collect and track performance data.

from activity-stream.