Closed Bug 598887 Opened 14 years ago Closed 8 years ago

Phishing protection should back off during OS Resume

Categories

(Toolkit :: Safe Browsing, defect, P5)

All
Windows 7
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ericj.bugzilla, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 3.0.30618; .NET CLR 3.5.30618; InfoPath.2; Tablet PC 2.0; Zune 3.0; .NET4.0C; .NET4.0E)
Build Identifier: 3.6.10

Phishing protection should back off during OS Resume to avoid interfering with the responsiveness of logon.  The Phishing feature periodically updates the database and writes out the sqlite file.  On laptop machines the writes can occur during resume thus impacting logon time.  It is more of a problem for users with laptops due to slower disks.

As an example, today during resume on my Win7 Toshiba laptop, Firefox read about 23 MB and wrote about 60 MB to C:\Users\*\AppData\Local\Mozilla\FireFox\Profiles\igrvz36w.default\urlclassifier3.sqlite and about 1 MB to *.sqlite-journal.  The elapsed time for the writes was 62 seconds.  

The problem is compounded for multiple user sessions.  (Win7 starter edition does not allow multiple accounts so that may not be an issue for some users.  The author of this bug shares machines with other family members each having a separate account.)

I would guess the cause is cache invalidation due to timeout.  This would cause a "thundering herd" problem of waking up to do work at an inconvenient time.

Reproducible: Didn't try

Steps to Reproduce:
1. On a Win7 laptop, log on and start Firefox
2. Close the case.
3. Wait 45 minutes (or time sufficient to invalidate the phishing cache).
4. Open the case.

You could use Windows Performance Analyer (xperf) to trace the physical disk IO:
xperf -on base
pause
rem ... close the case, wait an hour, open case and log in
xperf -d mytrace.etl

Actual Results:  
During resume I measured 23 MB physical reads and 60 MB physical writes over 62 elapsed seconds during resume (entering password).  UI was barely responsive during this time.

Expected Results:  
Responsive login experience.

For background on the Phishing Protection feature see https://wiki.mozilla.org/Phishing_Protection:_Design_Documentation#Client_Backoff

See also related bugs:
Bug 518234 - Allow urlclassifier lookup into only one table
Bug 329714 - check for performance impact (phishing protection)
Bug 466173 - RFE: per-profile firefox anti-phishing urlclassifier3.sqlite is wasteful, want system-wide copy
Changed Importance from Normal to Trivial.  In several subsequent Resumes on the same machine, the IO for this file were either much smaller (e.g. 2 MB) or did not occur.
Severity: normal → trivial
(In reply to ericj from comment #1)
> Changed Importance from Normal to Trivial.  In several subsequent Resumes on
> the same machine, the IO for this file were either much smaller (e.g. 2 MB)
> or did not occur.

... To the point where this is effectively a duplicate of another bug?
Flags: needinfo?(ericj.bugzilla)
Product: Firefox → Toolkit
Priority: -- → P5
This is probably no longer an issue given the sqlite backend was replaced with less expensive one.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(ericj.bugzilla)
You need to log in before you can comment on or make changes to this bug.