Closed
Bug 1074789
Opened 10 years ago
Closed 10 years ago
Regression detected for DNS_RENEWAL_TIME on the 25th of September
Categories
(Core :: Networking: DNS, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: rvitillo, Assigned: sworkman)
References
Details
Attachments
(1 file)
5.99 KB,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
Comment 1•10 years ago
|
||
The link does not work for me.
Reporter | ||
Comment 2•10 years ago
|
||
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
Reporter | ||
Comment 3•10 years ago
|
||
Could this be due to Bug 939318?
Assignee | ||
Comment 4•10 years ago
|
||
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?
Reporter | ||
Comment 5•10 years ago
|
||
(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.
Assignee | ||
Comment 6•10 years ago
|
||
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)
Assignee | ||
Comment 7•10 years ago
|
||
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e672f92d371d
Updated•10 years ago
|
Attachment #8499840 -
Flags: review?(mcmanus) → review+
Assignee | ||
Comment 8•10 years ago
|
||
Fixed build issue on try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=7888ecac404e
Assignee | ||
Comment 9•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2162376e065
Comment 10•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b2162376e065
Assignee: nobody → sworkman
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Reporter | ||
Comment 11•10 years ago
|
||
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.
Flags: needinfo?(sworkman)
Comment 12•9 years ago
|
||
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
Assignee | ||
Comment 13•9 years ago
|
||
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)
Comment 14•9 years ago
|
||
I filed bug 1160903 to add the telemetry probes.
Flags: needinfo?(valentin.gosu)
Assignee | ||
Comment 15•9 years ago
|
||
Thanks Valentin!
You need to log in
before you can comment on or make changes to this bug.
Description
•