Open Bug 1329486 Opened 8 years ago Updated 2 years ago

Poor HTTPs performance. Firefox 50.1.0 windows vs Chrome. Speedtest

Categories

(Core :: Networking, defect, P3)

50 Branch
x86_64
Windows 10
defect

Tracking

()

UNCONFIRMED
Performance Impact low
Tracking Status
platform-rel --- -

People

(Reporter: josecastilloalvarez, Assigned: acreskey, NeedInfo)

References

Details

(Keywords: perf, Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Steps to reproduce: Go to any internet speedtest using https, by example: www.testdevelocidad.es Actual results: On windows, with FF 50.1 poor performance occurs during speedtest. Both Websocket and XMLHTTPRequest connections affected if https is being used. Chrome and IE/Edge works fine. FF on Linux working fine. Please check badges: Chrome (windows) https://testdevelocidadgratis.com/badge/5872384147e0d961e0127577.png Firefox windows (poor results): https://testdevelocidadgratis.com/badge/587236cc47e0d961e0127478.png Firefox on linux: https://testdevelocidadgratis.com/badge/5872389647e0d961e01275a7.png Expected results: In that case, results would be arount to 300/300
Component: Untriaged → General
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Component: General → Networking
Product: Firefox → Core
this is a really high bandwidth target.. and we've got a bug open on that somewhere this should be dup'd to.
daniel I think you worked on what this should be dupd against.. do you recall the bug
Flags: needinfo?(daniel)
Whiteboard: [necko-next]
I recall a previous bug in this style but I've tried all sorts of searches now without finding it again! =( I'm however fairly sure that was a Mac issue and not windows like this one. I wonder how easily reproducible this is. I figure a lot of people use Firefox/Windows to download things from within company LANs etc where they would expect this or higher speeds. Jose: I assume those tests with other browsers were done on the *same* physical Windows installation? Do you happen to run any anti-virus on it? Have you verified that the problem remains when run on a clean profile with add-ons?
Flags: needinfo?(daniel) → needinfo?(josecastilloalvarez)
(In reply to Daniel Stenberg [:bagder] from comment #3) > I recall a previous bug in this style but I've tried all sorts of searches > now without finding it again! =( I'm however fairly sure that was a Mac > issue and not windows like this one. > > I wonder how easily reproducible this is. I figure a lot of people use > Firefox/Windows to download things from within company LANs etc where they > would expect this or higher speeds. > > Jose: I assume those tests with other browsers were done on the *same* > physical Windows installation? Do you happen to run any anti-virus on it? > Have you verified that the problem remains when run on a clean profile with > add-ons? Daniel: Chrome (Windows), IE and Edge was on the same machine that Firefox. No addons/services on the same machine, currently used only for check testdevelocidad.es under Windows. I've lots of reports of users with same problem. Before https migration all works fine (no differences between browsers/platforms).
Which https migration are you talking about? Are you saying this difference is only notable on HTTPS and not HTTP?
(In reply to Daniel Stenberg [:bagder] from comment #5) > Which https migration are you talking about? Are you saying this difference > is only notable on HTTPS and not HTTP? Yes, the issue is only over HTTPS. With HTTP Working fine (excuse my english).
Blocks: QF-Websites
platform-rel: --- → ?
platform-rel: ? → -
Whiteboard: [necko-next] → [necko-next][qf]
Whiteboard: [necko-next][qf] → [necko-next][qf:p1]
I got 14Mbps in both Chromium trunk and Firefox nightly, which I'm pretty sure is the max I can get in my current workspace, so the bottleneck is preventing me from reproducing this. I did take a peek with xperf and found the parent process spending large amounts of time in nsSocketTransportService::Poll, the content process main thread in PresShell::Paint (Are we perhaps over-painting in response to the page's speedometer?), and the compositor process in LayerManagerComposite::UpdateAndRender. Bas: I bet you have a faster ISP than me, and you know Windows. Can you see if you can reproduce this? Does something in your profiles start to look different than mine as the download speeds go higher?
Flags: needinfo?(bas)
Attached file bug1329486xperf.txt (deleted) —
xperf stacks at 14Mbps
I fired up Firefox 53 (32 bit) on Windows 10 on my lowly laptop just now. There seems to be something to this report, even if I cannot reproduce a *major* speed difference. Here's what I learned: I max out my 100mps connection against https://fast.com/ with Firefox. I then downloaded an 8GB file from my linux server over my 1gbit LAN (over HTTPS), and then the Firefox download manager reported roughly 70MB/second. Chrome 58 (64 bit) downloaded just now, downloads the same URL over HTTPS at a little over 90MB/second. The same 8GB file downloaded over HTTPS using curl from the same machine maxes it at 100MB/second.
(In reply to Daniel Stenberg [:bagder] from comment #9) > I fired up Firefox 53 (32 bit) on Windows 10 on my lowly laptop just now. > There seems to be something to this report, even if I cannot reproduce a > *major* speed difference. Here's what I learned: > > I max out my 100mps connection against https://fast.com/ with Firefox. > > I then downloaded an 8GB file from my linux server over my 1gbit LAN (over > HTTPS), and then the Firefox download manager reported roughly 70MB/second. > > Chrome 58 (64 bit) downloaded just now, downloads the same URL over HTTPS at > a little over 90MB/second. > > The same 8GB file downloaded over HTTPS using curl from the same machine > maxes it at 100MB/second. Daniel, It appears that the difference between FF and Chrome is greater at more speed. I can only confirm the issue when uses Javascript (both XHR and websockets), not sure about direct download. Maybe you can try in your LAN using Javascript (not curl or direct download), and don't forget the upload. Issues affecting both download and upload. I can help you with your LAN testing. If you like I can send you a server binary and provide a basic javascript client.
Flags: needinfo?(josecastilloalvarez)
I have a 1 Gb/s connection. Against https://www.fast.com I get 500 Mbps reported against all browsers (Edge, Chrome and Firefox). Against speedtest.net, which doesn't seem to support https, I get 650 Mbps on Chrome, 750 Mbps in Firefox and 850 Mbps in Edge. https://www.speedtest.org/ I get 300 Mbps in Firefox. And it doesn't seem to work on Edge or Chrome. 'www.testdevelocidad.es' seems to get different speeds on different reloads (75% of the time it won't even start), but none of them 'very' good in any browser for my ISP. I assume this is a geography issue. If any has other websites to suggest I can look at those. I highly doubt graphics could significantly affect this though, but maybe I'm wrong. On a sidenote, I should mention the performance of the animation when it slides out is very janky on Firefox compared to Edge and Chrome. This is interesting.
Flags: needinfo?(bas)
(In reply to Bas Schouten (:bas.schouten) from comment #11) > I have a 1 Gb/s connection. Against https://www.fast.com I get 500 Mbps > reported against all browsers (Edge, Chrome and Firefox). > > Against speedtest.net, which doesn't seem to support https, I get 650 Mbps > on Chrome, 750 Mbps in Firefox and 850 Mbps in Edge. > > https://www.speedtest.org/ I get 300 Mbps in Firefox. And it doesn't seem to > work on Edge or Chrome. > > 'www.testdevelocidad.es' seems to get different speeds on different reloads > (75% of the time it won't even start), but none of them 'very' good in any > browser for my ISP. I assume this is a geography issue. > > If any has other websites to suggest I can look at those. I highly doubt > graphics could significantly affect this though, but maybe I'm wrong. > > On a sidenote, I should mention the performance of the animation when it > slides out is very janky on Firefox compared to Edge and Chrome. This is > interesting. Bas: https://testvelocidad.eu/
(In reply to Jose from comment #12) > (In reply to Bas Schouten (:bas.schouten) from comment #11) > > I have a 1 Gb/s connection. Against https://www.fast.com I get 500 Mbps > > reported against all browsers (Edge, Chrome and Firefox). > > > > Against speedtest.net, which doesn't seem to support https, I get 650 Mbps > > on Chrome, 750 Mbps in Firefox and 850 Mbps in Edge. > > > > https://www.speedtest.org/ I get 300 Mbps in Firefox. And it doesn't seem to > > work on Edge or Chrome. > > > > 'www.testdevelocidad.es' seems to get different speeds on different reloads > > (75% of the time it won't even start), but none of them 'very' good in any > > browser for my ISP. I assume this is a geography issue. > > > > If any has other websites to suggest I can look at those. I highly doubt > > graphics could significantly affect this though, but maybe I'm wrong. > > > > On a sidenote, I should mention the performance of the animation when it > > slides out is very janky on Firefox compared to Edge and Chrome. This is > > interesting. > > Bas: https://testvelocidad.eu/ I get best transfer rates from Adamo(Sevilla) there: Firefox: 290 Mbps Edge: 220 Mbps Chrome: 260 Mbps
[for the qf triagers - I think this is pretty nichey and probably not a qf:p1 bug - there is no data to suggest this is a general impactful problem for our target qf cases.] The only slowdown I can measure is on my win10 laptop where a 2GB https:// download on my 1Gbit LAN runs at about 80% of the speed of http:// (on the order of 800mbit/s). However, chrome runs at the same ratio for that test - so its probably the cpu load of the cipher suite at this really high bandwidth. When I repeat the test on my more parallel and beefier desktop ff and chrome both run at the same ~800mbit rate. So that sounds like the same bottleneck for both browsers. Any tests I do of external services, such as testvelocidad, run at my line-rate for Internet connectivity (60mbps) for https. That site doesn't seem to have an http version anymore to compare with - but it can't run faster than my line rate :)
I'm going to lower the qf priority on your recommendation.
Whiteboard: [necko-next][qf:p1] → [necko-next][qf:p3]
I am able to reproduce the BUG in the current version of Firefox. It appears to happen over both HTTP and HTTPS. Though HTTP seems to get only s slightly better result, it is still low. This on a fresh install, no addons. The issue is repeatable and consistent. My machine has 32Gb ram and an i7 6700k at 4.2Ghz. (Yes, 4.2) So, I would not agree it is a machine issue. I am running Arch Linux.
Priority: -- → P2
Keywords: perf
Priority: P2 → P3
Whiteboard: [necko-next][qf:p3] → [necko-triaged][qf:p3]
Performance Impact: --- → P3
Whiteboard: [necko-triaged][qf:p3] → [necko-triaged]
Severity: normal → S3
Assignee: nobody → acreskey

This is a very old bug but we are looking to add download performance tests to match our upload performance tests, so I can have a look at this.

Flags: needinfo?(acreskey)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: