URLCLASSIFIER_LC_PREFIXES and URLCLASSIFIER_PS_CONSTRUCT_TIME histograms have changed

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: rvitillo, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40 affected)

Details

The telemetry alerting system identified a change in URLCLASSIFIER_LC_PREFIXES [1] and URLCLASSIFIER_PS_CONSTRUCT_TIME [2] on the 23rd of April.

The size of the prefix cache and the time spent constructing it has shrunk. Is this expected?

[1] http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/244/alerts/?from=2015-04-23&to=2015-04-23
[2] http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/111/alerts/?from=2015-04-23&to=2015-04-23
Copying from email to francois:

> It seems like it's when we create an in-memory lookup table with
> some recent update data? It seems like it's counting the number of
> hash prefixes that end up in these in-memory caches?

Yes. Specifically, it measures the number of entries in the database,
given that the number of prefixes we keep in RAM is equal to that. (Ok,
strictly speaking: minus sub chunks)

So this alert (and the associated graph) is telling us the size of the
databases has dropped.

This could be either:
1) Updates being broken, which is very bad.
2) The unwanted database starting to update and pulling down the
average, which would be expected.

> I also found a similar alert in March: 
> https://groups.google.com/forum/#!topic/mozilla.dev.telemetry-alerts/wqRRr4S3wko

This was when the fragmentation problem occurred due to adding an extra
list in Nightly, IIRC.
I think we would have noticed if updates had been broken in the last year so I assume this was due to the new lists.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.