Ts regression following checkins for anti-phishing (bug 358299)

NEW
Unassigned

Status

defect
11 years ago
5 years ago

People

(Reporter: alqahira, Unassigned)

Tracking

(Depends on 1 bug, {perf, regression})

Dependency tree / graph
Bug Flags:
camino2.0 -

Details

Anti-phishing produced a significant Ts regression in the static builds once we got them working (it earlier produced a significant Ts regression, and a slight Tp regression, on shared builds aka boxset).

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino&maxdate=1233613303&legend=0&norules=1

cb-xserve01:	1064->		     1064
		1079 1081 1079 1079  1079.5	 1.45%
       
cb-minibinus01: 1152 1149 1153 1148  1150.5
		1272 1222 1281 1249  1256	 9.17%

h-103 has been giving very erratic Ts results lately, so I have omitted it.

Just for completeness, here are the numbers from boxset from the initial checkin (where only shared worked):
       
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino&maxdate=1233227800&hours=24&legend=0&norules=1

boxset:		1385 1383 1386 1383  1384.25
		1640 1638 1656 1654  1647	 18.98%
          
boxset-tp:	534 537 534 538	     535.75
		539 545 540 542	     541.5	 1.06%

Questions:
1) Can we do anything to ameliorate this Ts hit?
2) Did Firefox experience a similar Ts hit when they started loading the safebrowsing/url-classifier components?
Flags: camino2.0?
In addition to finding answers to those questions, we should try locally 

1) making the pref URLs valid, so there's no 503 error involved
2) turning safebrowsing off

and see how either or both of those affect Ts (I'll use minus, since it was most sensitive).
minus has ranged between about 1220 and 1280 (with spikes to as high as about 1330) in the past few days.

I locally set both safebrowsing.enabled prefs to false, which dropped Ts to just below 1220 initially.  The swing now is much narrower, ranging between 1220 and about 1245 over 10 cycles (though the initial cycle with the change was still 1290(!)
After comment 2, I locally made the provider URLs all valid URLs (which I think should have been a no-op as long as the prefs were both still set to off, as they were), and for the most part we continued to maintain the 1220-1260ms range, with the occasional spike to about 1300ms.
And with safebrowsing on and valid provider URLs, we were back to the 1220-1300ms swing.

Based on these tests and the fact that the static builds didn't show the Ts regression until they were loading the component, it's looks like it's all the component and/or loading it.  (I suppose I could technically back out the nsStaticComponents.cpp part of the patch and verify that we drop back down to prior levels and prior swing ranges.)
Not for 2.0, although it's unfortunate we took a startup hit :(
Flags: camino2.0? → camino2.0-
You need to log in before you can comment on or make changes to this bug.