277056 - HTTP POST requests with XMLHttpRequest are extremely slow in Mozilla.

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[rpenikal]

BMC's Remedy line of enterprise software has over 10 million users (is this 
correct). Our enterprise applications rely heavily on the usage of the 
XMLHttpRequest object to do synchronous HTTP POSTs for invoking business logic 
from the web browser. Our usage is straightforward, as follows:

	fetcher=new XMLHttpRequest();
	fetcher.open("POST",url,false);
	fetcher.setRequestHeader("Content-type","text/plan; charset=UTF-8");
	try {
		fetcher.send();
	} catch(e)
	...

We find that on both 100mbit and gigabit ethernet networks (with both browser 
and web server idle, servicing no additional clients and no other programs 
running), connected via varying topologies, from both Unix and Windows 
browsers, the call to fetcher.send() above will typically take between 100ms to 
350ms, for small amounts of data both sent and returned. During this time, the 
client CPU also spins, although this is less of an issue for us.

From the exact same Mozilla browser machines, using a Java applet (using 
URLConnection class) to do the same HTTP POST request, the same calls typically 
takes 20ms to 40ms. Internet Explorer on the same machine also takes 20ms to 
40ms to do the post using the Msxml2.XMLHTTP object.

The poor performance of this call in Mozilla is making our enterprise 
applications feel significantly less responsive on Mozilla compared to IE.

Using Applet is not an option, in our earlier version we did use Applet and 
several compatibility issues between JRE/brosers verisons have caused major 
issues. Hope to see this bug is triaged ASAP and being fixed in 1.7.x .

Comment 1

[Elaine]

Attachment: testcase for this bug

unzip the file into a folder and deploy it to your web server. Open test.html

Comment 2

[john fang]

additon: In order to let java applet access the web, you should configure the
some ".policy". If the server is "localhost",it is not necessary.


setp

1.New a file named "testapplet.prolicy". Then add 
"grant {
  permission java.net.SocketPermission "server", "accept,connect,listen,resolve";
};
"
in this file.  server means the addr of the server for example
"129.158.217.233:8080"

2.copy "testapplet.prolicy" to "${JRE_HOME}/lib/security/"
3.open the file "${JRE_HOME}/lib/security/java.security"
4.find
"policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
"in this file
5.add  "policy.url.3=file:${java.home}/lib/security/testApplet.policy" below them

Comment 3

[Elaine]

Comment on attachment 171278 [details]
testcase for this bug

This test should be done from a remote system

Comment 4

[Boying Lu]

Attachment: patch

Comment 5

[Boris Zbarsky [:bzbarsky]]

Isn't this a duplicate of bug 273578?

Comment 6

[alexander :surkov (:asurkov)]

The same thing I see when I send async HTTP GET request by XMLHttpRequest
object. When I send request at first time then I wait in 16 seconds
approximately. At next times I wait in 3 seconds.

var it=new Date();

requestor=new XMLHttpRequestor();

requestor.open("get", httpurl, false);
requestor.send(null);
var doc=requestor.responseXML;

var ft=new Date();
alert(ft-it);

When I load local file with XMLHttpRequest then I wait in 0 miliseconds.

I'm not shure is it the same bug or something else?

Test platfrom: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b)
Gecko/20050217

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 9

[rpenikal]

This is critical for BMC's business applications as many customers don't have any other alternative to mozilla hence I am reopening this defect for possible tracking by the team to resolve in a patch.

Comment 10

[Andrew Schultz]

What product are you still seeing this bug in?

Comment 11

[Wayne Mery (:wsmwk)]

BMC, can you confirm by testing?

bz in comment #5:
> Isn't this a duplicate of bug 273578?

if so it should be gone per Darin. (and patch is obsolete)
but customer won't see it til FF 3?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment 5 refers to the patch in comment 4.

The original bug doesn't seem to be what comment 4 is trying to fix, necessarily.

[e-mail], do you see your problem with a trunk ("Minefield") build?  Knowing the answer to that question is the first step to figuring out exactly what's going on with this bug.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Note that I can try setting up this testcase against a local web server (to minimize network latency).  But it'll be a pretty crappy web server, and running on the same machine, which may skew the results.  And there's no way I can try this until next week.  If there's someone else who can set up a test for this, that would be great.

Comment 14

[Martijn Wargers (dead)]

I tried the testcase on a local webserver, I used the test.html file as the xmlhttprequest object.
I get something like 16 ms, both on 1.8.1 branch builds as on trunk builds, so I guess I don't see the problem.

Comment 15

[Boris Zbarsky [:bzbarsky]]

See comments in bug 360692?  But note that I cannot reproduce the large lag times described in this bug; I get times on the order of 200ms when going from Chicago (client) to California (server), with a DSL line at one end.

Comment 16

[Matthias Versen [:Matti]]

[e-mail] never responded (comment #12) , marking wfm