Closed Bug 634124 Opened 13 years ago Closed 12 years ago

Startup time reports

Categories

(Mozilla Metrics :: Frontend Reports, defect)

Product:
Mozilla Metrics
Component:
Frontend Reports
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Critical/Firefight

People

(Reporter: taras.mozilla, Unassigned)

References

Details

(Whiteboard: Telemetry P2 migrated to JIRA) 

Since bug 623950 landed we have pretty good data on Firefox startup speeds. We don't yet have is a good analysis of the data.

Would be nice to able to rely on those numbers for tracking performance between builds.

I would like to be able to rely on startup reports from nightlies similar to how we use Ts data. ie get notifications that "build x is 20% slower/faster than previous builds".

In addition I would like to know that the majority of our users experience startups between x and y seconds. 

This would later be extended to memory use, UI latency, etc
(adding bit more description to the bug)

Telemetry - https://wiki.mozilla.org/Platform/Features/Telemetry allows us to gain insights on different features that are used by Fx 4 users. Google extensively tests/gather's metrics on each feature that is released in its browser Chrome.

The metrics team will be building a collection interface that will accept JSON input via REST call, insert the data inside HBase asynchronously and make it available for further offline analysis to different teams.

@taras: can u confirm the load testing metrics below:
Load testing:
Expect a daily input of approximately 20M requests/day, peak 200K/minute.
Assignee: nobody → aphadke
(In reply to comment #1)

> @taras: can u confirm the load testing metrics below:
> Load testing:
> Expect a daily input of approximately 20M requests/day, peak 200K/minute.

I can't confirm this as I never had to count our users before. Perhaps someone at AMO who deals with frequent AMO pings can confirm this number.
I told Anurag in IRC that we should plan on handling 200m requests per day and expect a similar distribution of requests to our blocklist requests.  This is based on the current draft plan of using an idle timer to submit once per day.
sample table and REST request.

create 'telemetry_data', {NAME=>'metrics', COMPRESSION => 'LZO', VERSIONS => '1'}

curl -H "Content-Type: text/xml" --data "<CellSet><Row key=\"ZmNlNjg2YmMtYjQxYi00ZGI1LWE1MzgtNTcxOTFlZjFhOTlj\"><Cell column=\"bWV0cmljczpqc29u\">eyJtZXRyaWMzIjogMywgIm1ldHJpYzIiOiAyLCAibWV0cmljMSI6IDF9</Cell></Row></CellSet>" http://hp-node33.phx1.mozilla.com:8080/telemetry_data/fce686bc-b41b-4db5-a538-57191ef1a99c/metrics:json


Next step includes load test via "ab" - apache bench.
load test was done wrt a different bug and the current code base for bagheera https://github.com/mozilla-metrics/bagheera/ passed the test without any hiccups.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(closed the bug by mistake)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [Telemetry:P2]
Group: metrics-private
Closing. Unresolved bits of this should be opened in a new JIRA for tracking.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
updated whiteboard field
Whiteboard: [Telemetry:P2] → Telemetry P2 migrated to JIRA
updating status and assignee
Assignee: aphadke → nobody
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
New JIRA migration identifier - 55 BZ issues being considered in current planning for Q3
Target Milestone: Unreviewed → Targeted - JIRA
reopened by mistake
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: Moved to JIRA → Critical/Firefight
You need to log in before you can comment on or make changes to this bug.