Large text POST data causes 100% CPU utilization

RESOLVED WORKSFORME

Status

()

Core
Networking
RESOLVED WORKSFORME
9 years ago
6 years ago

People

(Reporter: UNHchabo, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

I'm implementing a modified version of the Speedtest linked above on my local network (100Mbit), and while IE6 and IE7 report speeds close to the line rate of 100Mbps, both FF2 and FF3 report significantly lower speeds, usually no higher than 10Mbps. FF seems to go to 100% CPU utilization while downloading the POST data for the download test, or while uploading the POST data for the upload test.

Reproducible: Always

Steps to Reproduce:
1. Put the speedtest on a local network computer.
2. Run in Internet Explorer, analyze the results.
3. Run in Firefox, analyze the results.
Actual Results:  
Firefox goes to 100% CPU utilization, and yields lower results for the speedtest.

Expected Results:  
Firefox should yield results of close to the network line rate, as Internet Explorer does.

This bug occurs on all tested platforms, including Firefox 2 and 3, and in Windows XP, Linux, and MacOSX.
(Reporter)

Comment 1

9 years ago
Just to clarify, this is also still present in the nightly build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080827031643 Minefield/3.1a2pre

I just happened to submit the bug using FF2.
Component: General → Networking
Product: Firefox → Core
Version: unspecified → Trunk
QA Contact: general → networking
Sorry, what do you mean with: 1. Put the speedtest on a local network computer. ?
(Reporter)

Comment 3

9 years ago
By "Put the speedtest on a local network computer", I meant that the above-linked speedtest should be installed onto a webserver on the same LAN as the user, so that the network being tested is the LAN, not the public Internet. That way Firefox's bottleneck will be made apparent, putting CPU utilization at 100%.

As I said earlier, Firefox shows a bottleneck at about 10Mbps for this test, and I'm running it over a 100Mbps network.
(Reporter)

Comment 4

9 years ago
Just an update: The client machines previously being used were Athlon XPs and Athlon 64s -- all single-core CPUs from at least two generations ago. My usual download speeds were around 15Mbps for 4MB of data, and about 3Mbps for 20MB of data.

Today I was able to test this web app using a Core 2 Duo E4500. One core went up to 100% utilization, and I got 35Mbps for 4MB of data, and 5Mbps for 20MB of data.

So CPU speed does definitely help with this app, but it shouldn't be dependent on the CPU; this app should record speeds at line rate.
This speedmeter seems to be unreliable. It returns completely insane values when upload metering and pretty version are disabled. I got speed 6169Mbps using FF and 3564Mbps using Opera when downloading 20MB over 100Mbit ethernet.

It shows quite reasonable results when upload is disabled and pretty version enabled. Results of 20MB download:
FF 3.6a1pre    85Mbps
ie 6 (in WINE) 49Mbps
Opera 9.27     89Mbps

Download speeds are too low when upload metering is enabled because upload data is concatenated in 50kb chunks. So the more data is received the more data must be handled in JS and the slower the download is. Results of 20MB download:
FF 3.6a1pre    7.5Mbps
ie 6 (in WINE) 1Mbps
Opera 9.27     27.5Mbps
Opera doesn't update progress bar continuously. It interprets most of JS code after it download all data and also it interprets it in another order because whole operation takes around 22 seconds what should give 7.3Mbps and not 27.5Mbps. So the ending timestamp is definitely taken before upload data is concatenated.


I've done my own test to see if there is some bottleneck in necko. I've created simple CGI script that returns 2GB of data from /dev/zero. I've downloaded it from localhost to /dev/shm to avoid slowdown due to network throughput and disk I/O. Firefox's result is subaverage but IMHO acceptable:

FF 3.6a1pre     604 Mbit/s
ie6 (in WINE)   744Mbit
Arora 0.5       1060 Mbit/s
Konqueror 4.2.1 252 Mbit/s
Opera 9.27      1347 Mbit/s
wget 1.11.4     1787 Mbit/s

Comment 6

7 years ago
Something similar (100 % CPU on one core) is still reproducible with brand-new Firefox 4.0 (Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20110321 Firefox/4.0).

I just started a big file upload to Amazon Cloud Drive. While the upload is in progress, Firefox is constantly using 100 % of one CPU core.
david, thanks for updating the bug.. I'll put this in my queue of things to see if I can reproduce.
(In reply to comment #6)
> Something similar (100 % CPU on one core) is still reproducible with brand-new
> Firefox 4.0 (Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20110321 Firefox/4.0).
> 
> I just started a big file upload to Amazon Cloud Drive. While the upload is in
> progress, Firefox is constantly using 100 % of one CPU core.

Is that just a normal form based file upload or is there some whiz bang extension, flash, or applet involved?

This is WFM without more information from the problem reporters..

I just uploaded a 50MB file via http://www.ducksong.com/misc/452458.html.. it ran at 1Mbit/sec, which is what my cable modem does, for about 7 minutes.. my CPU utilization was never more than 2 or 3 percent on my quad core i5. That's pretty much what I expected.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.