Enabling safebrowsing provider urls in performance tests is improving loadtime
Categories
(Toolkit :: Safe Browsing, task, P3)
Tracking
()
People
(Reporter: acreskey, Unassigned)
Details
I wanted to see the impact of disabling safebrowsing on raptor pageload tests.
But it's disabled in the test framework.
So I made a comparison in which I enable it by removing the above prefs.
And the strange thing is that pageload is improved in raptor when I re-enable safebrowsing:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=190b8f87707ac2e16c9d94003310fec1700a14ad&newProject=try&newRevision=c5ef97f580f929579670912ee33d27bc020eb4c6&framework=10
e.g. 9% overall on bing, what look to be solid 5% and 6% on amazon and google.
I can get the same results by simply removing the dummy local host urls from the prefs:
https://hg.mozilla.org/try/rev/6676df5f8da550a9f4862e26e9372e08468f7d99
e.g. user_pref("browser.safebrowsing.provider.google.gethashURL", "http://127.0.0.1/safebrowsing-dummy/gethash");
I believe that the minimal change to reproduce this performance gain (at least on bing) is:
https://hg.mozilla.org/try/rev/6d65c5dc88ba1af03beb17812da57a50ccfc9e68
I've logged this bug to so we can discuss this.
Dimi Lee raised this idea:
Maybe this is because the optimizations we have done by using tracking protection, See
"Tracking annotations" in this link : https://wiki.mozilla.org/Security/Tracking_protection
The preferences used in the performance tests may be bypassing important networking features.
Comment 1•6 years ago
|
||
Can you help set the pref - "privacy.trackingprotection.annotate_channels" to false and see the performance change?(together with the patch that removing the dummyy local host)
The preference should disable all those networking features, so if you still see a performance gain after doing that, maybe it is not the root cause.
Reporter | ||
Comment 2•6 years ago
|
||
Ah, it turns out that privacy.trackingprotection.annotate_channels
is already set to false in the performance tests and so also in those tests of mine:
https://searchfox.org/mozilla-central/rev/ab6f4c453d15ab82147c630a8b886b40240ca72b/testing/profiles/perf/user.js#87
Comment 3•6 years ago
|
||
(In reply to Andrew Creskey from comment #2)
Ah, it turns out that
privacy.trackingprotection.annotate_channels
is already set to false in the performance tests and so also in those tests of mine:
https://searchfox.org/mozilla-central/rev/ab6f4c453d15ab82147c630a8b886b40240ca72b/testing/profiles/perf/user.js#87
I see, thanks for helping verify this. Not sure if it is because that we do something redundant which slows that performance while using dummy url.
Set this to p3 because it is an anti-bug
Reporter | ||
Comment 4•6 years ago
|
||
Good stuff.
I'll try some experiments and do some profiling to see if I can figure this out.
Reporter | ||
Comment 5•6 years ago
|
||
Hmm.
So I tried these options:
• disabling the registration of the safebrowsing tables
• removing the error handling retry (thinking that perhaps the repeated failed requests were causing bottlenecks
But neither had any measureable performance impact.
Removing the dummy urls does still give some noticeable performance improvements.
e.g. early metrics on google
My local devices are mostly tied up in test runs so I haven't been able to try to catch the difference with profiling.
It's also a relatively subtle improvement, so it may be tricky to spot in profile comparisons.
Anyone have any ideas on next steps?
I will try profile comparisons once my devices are free.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 6•5 years ago
|
||
Not working on this as we're moving off from raptor pageload tests.
Ultimately, we are working on having all of SafeBrowsing and Tracking Protection enabled in the browsertime performance tests:
https://github.com/sitespeedio/browsertime/issues/1211
Updated•2 years ago
|
Description
•