Closed Bug 650709 Opened 13 years ago Closed 13 years ago

Suspiciously high performance impact reported for Personas Plus and SimilarWeb on Windows 7

Categories

(Testing :: Talos, defect, P2)

x86
Windows 7
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jorgev, Unassigned)

References

()

Details

Attachments

(1 file)

If you look at the results of the last run, on Windows 7 both Personas Plus and SimilarWeb have extremely high impact percentages (201% and 221%, respectively). At least in the case of Personas Plus this is making the add-on appear on the top slowness list when it probably shouldn't be there (although it comes close anyway).

We should investigate the cause of these discrepancies, and discard the Windows 7 results for both these add-ons, or all of them if we discover this is a more general problem.
Personas Plus slowdown appears to be real - I also get 2 seconds additional delay on my Windows 7 machine. Reason seems to be the Groovy Blue persona that is selected by default. If I change extensions.personas.selected pref default in the extension package from "current" to "default" (use the regular Firefox 4 theme) I get only 70 ms delay. Why the same slowdown doesn't appear on other platforms is a good question.
The delay caused by SimilarWeb is also real, more than 2 seconds for me (very noticeable even without about:startup). This element in chrome://similarweb/content/toolbar.xul (a browser overlay) is responsible:

<toolbaritem id="googleAnalytics">
 	<iframe type="content" src="http://analytics.similarweb.com/similarweb_ff.html?type=2" height="0" width="0" collapsed="true"/>
</toolbaritem>

Why the same frame supposedly doesn't cause delays on platforms other than Windows 7 is beyond me.
Please note that in case of Personas Plus selecting that ugly persona is really sufficient - after that you can disable the extension, the code built into Firefox will take over and still cause exactly the same slowdown.
My understanding is that Talos boxes run with all hosts redirected to localhost, so network latency doesn't factor in the tests. The delays shouldn't happen unless the Windows 7 tests are being run with a different setup.

I'll look into the issues you mentioned and contact the authors. Thank you for investigating this.
(In reply to comment #4)
> My understanding is that Talos boxes run with all hosts redirected to
> localhost, so network latency doesn't factor in the tests.

I'm not entirely sure about that. It does run with localhost:80 as proxy but if I see it correctly then there isn't anything on that port. So you might be measuring proxy connection timeout there. Not that a content frame should delay the browser window in the first place...
This reminds me of bug 617503. I don't have anything but suspicion there, though.
From comment #1 and comment #2 it appears that these are real regressions - can we close this bug as it is filed against talos?
Alice, can you shed some light on comment #5?
Talos runs the browser proxied to localhost.  Every talos slave has a local apache server - there should be no proxy timeouts affecting numbers.
(In reply to comment #6)
> This reminds me of bug 617503. I don't have anything but suspicion there,
> though.

It seems at least not unrelated. Changing the proxy from "localhost" to "127.0.0.1" results in 1 second slowdown instead of 2 seconds. Removing the proxy setting altogether results in again 0.5 seconds less delay. This is independent of whether I have a web server on port 80.
(In reply to comment #10)
> This is independent of whether I have a web server on port 80.

Sorry, that statement was wrong. I tried the fix from bug 617503, added this preference to the config file:

>  network.dns.ipv4OnlyDomains: localhost

This works. If in addition I have a web server on port 80 then I get the expected slowdown for SimilarWeb (200 ms).
Personas Plus is the same issue. Adding that pref reduces the slowdown to 100ms.
Would we like to have that pref added to the addon.config file?
I think it should be added, yes, given that its default value doesn't provide any benefits.
Comment on attachment 529817 [details] [diff] [review]
[checked in]add "network.dns.ipv4OnlyDomains: localhost" to addon.config

Review of attachment 529817 [details] [diff] [review]:

::: addon.config
@@ +54,5 @@
   extensions.firebug.net.enableSites : true 
   extensions.firebug.script.enableSites : true
   extensions.checkCompatibility.4.0 : false
   noscript.default: 'file:// about:blank about:credits addons.mozilla.org mozilla.net flashgot.net google.com gstatic.com googleapis.com securecode.com informaction.com yahoo.com yimg.com yahooapis.com maone.net noscript.net hotmail.com msn.com passport.com passport.net passportimages.com live.com js.wlxrs.com'
+  network.dns.ipv4OnlyDomains: localhost

not to be too picky, but all the other prefs have a space between the pref and the colon.  Just to keep it uniform, we should change this line to:
network.dns.ipv4OnlyDomains : localhost

Since we are not running these remotely, this is fine to assume localhost.
Attachment #529817 - Flags: review?(jmaher) → review+
Depends on: 651670
Comment on attachment 529817 [details] [diff] [review]
[checked in]add "network.dns.ipv4OnlyDomains: localhost" to addon.config

changeset:   236:d9bbd5b5917c
Attachment #529817 - Attachment description: add "network.dns.ipv4OnlyDomains: localhost" to addon.config → [checked in]add "network.dns.ipv4OnlyDomains: localhost" to addon.config
Deployed patch.

Please re-open is performance results are still not trusted.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: