The link does not work for me.
Valentin, sorry about that, we just moved that dashboard to another machine. Please use the following URL: http://telemetry-regressions-lb-1119531246.us-west-2.elb.amazonaws.com/index.html#/detectors/1/metrics/516/alerts/?from=2014-09-25&to=2014-09-25
Could this be due to Bug 939318?
I think it might be bug 1067679. We added a second async lookup to get DNS TTL - it would be considered as a renewal, and may be longer because it's actually two lookups internally. I don't know if bug 939318 is affecting it as well. But I'll work up a patch to put the async lookup in a separate bucket - DNS_RENEWAL_TIME_FOR_TTL or something like that. Maybe we can try that first?
(In reply to Steve Workman [:sworkman] from comment #4) > I don't know if bug 939318 is affecting it as well. But I'll work up a patch > to put the async lookup in a separate bucket - DNS_RENEWAL_TIME_FOR_TTL or > something like that. Maybe we can try that first? That makes sense, thanks.
Created attachment 8499840 [details] [diff] [review] DNSRenewalForTTL.diff Note: Pat made a good point offline earlier in the week: This increase in renewal time is probably due to Necko's cache expiration time being much more closely aligned with the OS resolver's expiration time when TTL is enabled. Without TTL enabled, there's a chance that the OS resolver cache has the record, meaning the function call for renewal will return very quickly. With TTL enabled, the renewal will most likely be a cache miss for the OS resolver and thus hit the network. So, it's not entirely unexpected that the function call to renew the record will take longer to complete. That said, this patch adds a few more histograms to separate the TTL experiment data: DNS_RENEWAL_TIME__TTL_ONLY_EXPT DNS_RENEWAL_TIME__TTL_PLUS_CONST_GRACE_EXPT --> to get the renewal time for the two experiments involving TTL. This means that DNS_RENEWAL_TIME should return to its former values. DNS_RENEWAL_TIME_FOR_TTL__TTL_ONLY_EXPT and DNS_RENEWAL_TIME_FOR_TTL__TTL_PLUS_CONST_GRACE_EXPT -- to get the renewal time JUST for the TTL. So, DNS_RENEWAL_TIME should just be for the current, non-TTL expiration of 2 mins + 1 min grace time; neither of the TTL experiments should be polluting that data. (And we'll get some more data on the renewals for the TTL experiments themselves).
Attachment #8499840 - Flags: review?(mcmanus)
Attachment #8499840 - Flags: review?(mcmanus) → review+
Fixed build issue on try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=7888ecac404e
Assignee: nobody → sworkman
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Steve, Could you set an alerting e-mail, and expiration date if applicable, for your new histograms? By setting an alerting email you are going to receive a notification when the distribution changes. Grep for "alert_emails" in https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe to know more about it.
It seems there was a regression in the HTTP_SUB_DNS_LOOKUP_TIME Telemetry histogram as a result of this bug: http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/1043/alerts/?from=2014-11-12&to=2014-11-12 I think it means it's taking us longer to do DNS lookups right after startup (before sessionstore-windows-restored event). - Is this an actual regression? - Can you file another bug to add a notification email address for Telemetry regression alerts related to the Necko histograms? You can create an email alias for this purpose in mozilla.service-now.com
Unfortunately, this has been waiting too long in my queue. Needinfo'ing Valentin to see if he can take it on.
Flags: needinfo?(sworkman) → needinfo?(valentin.gosu)
I filed bug 1160903 to add the telemetry probes.
You need to log in before you can comment on or make changes to this bug.