1161490 - URLCLASSIFIER_LC_PREFIXES and URLCLASSIFIER_PS_CONSTRUCT_TIME histograms have changed

Status: RESOLVED WONTFIX

(Toolkit :: Safe Browsing, defect)

Description

[Roberto Agostino Vitillo (:rvitillo)]

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

Comment 1

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 2

[François Marier [:francois]]

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.