360692 - XMLHttpRequest Object performance slowed down very badly (Since 1.5.0.5)

Status: RESOLVED DUPLICATE of bug 137155

(Core :: XML, defect)

Description

[Bug Tracker]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 2.0.50727)
Build Identifier: Firefox 2.0 and Firefox 1.5.0.5+

When runned against localhost everything seems okey. When runned from remote, Firefox 2.0 and Firefox 1.5.0.5 has gotten incredible slow. It is probably one of the security fixes done below;

MFSA 2006-56 chrome: scheme loading remote content
MFSA 2006-55 Crashes with evidence of memory corruption (rv:1.8.0.5)
MFSA 2006-54 XSS with XPCNativeWrapper(window).Function(...)
MFSA 2006-53 UniversalBrowserRead privilege escalation
MFSA 2006-52 PAC privilege escalation using Function.prototype.call
MFSA 2006-51 Privilege escalation using named-functions and redefined "new Object()"
MFSA 2006-50 JavaScript engine vulnerabilities
MFSA 2006-48 JavaScript new Function race condition
MFSA 2006-47 Native DOM methods can be hijacked across domains
MFSA 2006-46 Memory corruption with simultaneous events
MFSA 2006-45 Javascript navigator Object Vulnerability
MFSA 2006-44 Code execution through deleted frame reference

We started to issiue notes to our customers to not to use Firefox 2.0 and 1.5.0.5+ if it is not absolutely necessary. Because there is at least 100% performance lag between 1.5.0.5 and 1.5.0.4.

May be, there is a reason for not releasing security fixes without properly testing it. Your browser is going down the tubes if you apply security fixes this fast with couple of tests and reviews. It is better not to mention the would be security flaw to the public until you properly fix it .


Reproducible: Always



Expected Results:  
New versions should get faster rather than slower

Comment 1

[José Jeria]

Do you have any url or testcase so that this bug can be reproduced?

Comment 2

[Bug Tracker]

This is mind-blowing. Even old NN4 is faster than this browser now. All the event handlers work like a drunken turtle. When I switch back to Firefox 1.5.0.4 everything takes a breath. What did you guys do? Try any Ajax platform out there if a test case needed. Try with a below 1.7gigaherz machine. Do we have to download every single release and test our product with it? This is not going anywhere. Speaking of IE 7.0, it has 100% performance boost over IE6.0 on our product. Well, good riddance. Thanks to Microsoft.

Comment 3

[ReleaseEngineer]

Well, please ignore the over excited comments of the above poster. What we really experience is in fact not very good. We do not have a test case but as said above any multi iframe ajax platform would do for testing.

To mozilla team: This is very crippling for our relentless effort to support Firefox/Seamonkey. Please do not trash your image as an alternative web browser from your believers' mind.

Comment 4

[Bug Tracker]

Our recent finding shows this is about the performance of XMLHttpRequest object. It has gotton extremly slow.

       xma.open('POST','http://someofourremotesite/',true);
       xma.send(requestData);
       xma.onreadystatechange = processXML;

This is what we use, plus we do not create a new XMLHttpRequest object we reuse the existing one. Would it be that it is not clearing previous state before accepting new ones?

Comment 5

[Bug Tracker]

I created a new XMLHttpRequest object for each call, nothing has been improved.
It works okey on the localhost, it only gets creeped out from a remote machine. So something was bugged down on XMLHttpRequest object in 1.5.0.5 onward. It is very very slow.

Comment 6

[Bug Tracker]

Possible regressions by

https://bugzilla.mozilla.org/show_bug.cgi?id=339530
https://bugzilla.mozilla.org/show_bug.cgi?id=316159

Comment 7

[Bug Tracker]

It is sad to see only we have hit this bug. Bailing out.

Comment 8

[José Jeria]

Why do you mark this bug as INVALID? Have patience please.

Would it be possible for you to create a small testcase showing this bug?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

A testcase is needed.

Comment 10

[ReleaseEngineer]

I will try to write a testcase to simulate this problem; however, I do not have too much time in my hands so bear with me. That said, I believe the handling of "POST" in XMLHttpRequest object is lagging something if anyone would like to take a shot and see what has changed there.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Neither of the checkins mentioned in comment 6 should have had much effect on XMLHttpRequest performance....  For example, bug 339530 only has an effect if 4 or more args are passed to open() (which in your case isn't happening, per comment 4).

Testcase would really help; trying to convince us that problems should be fixed is silly -- we agree that they should be fixed.  ;)

And please, for the sake of whatever you hold holy, get the overexcited folks (or single person?) to calm down.  Marking a bug invalid because it didn't get fixed within 24 hours is ridiculous.

Comment 12

[ReleaseEngineer]

Boris, I agree. 

As an additional information, we use SSL if that may have anything to do with slowing down the XMLHttpRequest's POST operation which was not slow at all prior to 1.5.0.5.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Hmm...  That shouldn't matter....

I assume you guys have definitely tracked the problem to XMLHttpRequest?  Is the time between calling send() and having the readystatechange handler fire longer?  Or is the processing of the XML response longer?  Or both?

Comment 14

[ReleaseEngineer]

There is no XML in the response, and we do not make any XML processing in the browser side. I think both sending the request and receiving the response are very slow. I see that the requests are coming too slow to the server. Our program makes too many back to back requests; and, XMLHttpRequest object can not just keep up with them. In fact, I will try to demonstrate exactly that when I put my hands on to the testcase.

Comment 15

[ReleaseEngineer]

By the way, the "GET" operation on XMLHttpRequest object has gotten significantly faster; very good job on that indeed. The "POST",on the other hand, has gotten very very slow. I think this will narrow down some of your lookups. It would make more sense to change the summary of the Bug as "XMLHttpRequest Object 'POST' operation slowed down very badly (Since 1.5.0.5)"

Comment 16

[Martijn Wargers (dead)]

I was trying out something like this: http://wargers.org/xmlhttprequest_post.htm
That isn't slow for me, but probably the testcase isn't any good. (maybe I need to use ssl, like you said).
Could I perhaps see the web application in question to see if I can come up with a reduced testcase?

Comment 17

[ReleaseEngineer]

The web application is question is huge. Howabout posting something instead of just null?

<script>
var xma = new XMLHttpRequest();
var wait=false;
window.setInterval(post,50);

function processXML() {    
     if(xma.readyState==4) {
          if(xma.status==200) {
              var date2=new Date();
              alert(xmlobj.responseText+" time:"+(date2-date1));
              wait=false;
          }
     }
}

function post() {
  if(!wait) {
   wait=true;
   var date1=new Date();
   xma.open('POST','http://wargers.org/',true);
   xma.send("postmepostmepostmepostmepostmepostmepostme");
   xma.onreadystatechange = processXML;
  }
}
</script>

Comment 18

[ReleaseEngineer]

Uhm, yes there are typos;

corrections;
1."The web application in question is huge"
2."alert(xma.responseText+" time:"+(date2-date1));"

Comment 19

[ReleaseEngineer]

Attachment: example script

Comment 20

[Boris Zbarsky [:bzbarsky]]

So could someone possibly attach an HTML file that I could either just load or load and click a button in to reproduce whatever action it is that's measurably slower?

Comment 21

[Daniel Veditz [:dveditz]]

Would really love to fix this, and if we can identify a fix in time for the next releases we'll take it. But it's not going to hold the next release if we don't make progress.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Really need a page showing the problem to get somewhere here; I can't reproduce this in the few tests I've tried, and have limited time to spend on it...

Comment 23

[ReleaseEngineer]

I was unable not put a live demo on our server. Please be advised that this may well be a Windows XP SP2 problem (although there is no significant data to prove this). A machine slower than 1.7Ghz(at least from our tests) needed to see the problem clearly. Also, Server and firefox/seamonkey should not be on the same machine. 

It is very interesting that we are the only party having trouble with this bug. Looks like not alot of people have been using "POST".

Comment 24

[Boris Zbarsky [:bzbarsky]]

So does the "example script" attached to this bug not show the problem for you (if pointed at a dummy server of some sort)?

A slow machine is not a problem on this end, fwiw; I'm typing this on a P3-733... My problem is not having a page I can load to test.

Note that this need not be a public page; feel free to email me privately a test page or set of pages or information on how I can access something you set up or whatever.

> Looks like not alot of people have been using "POST".

Er... it's pretty commonly used, actually.  So either everyone is suffering and saying nothing or there's something special about your case...

Comment 25

[ReleaseEngineer]

Attached script should demonstrate the problem if the climate is right ;).

Boris, I will set up a page and email the address to you. But I will probably have time around friday to do that.

Comment 26

[Boris Zbarsky [:bzbarsky]]

So... this is _really_ weird.  The test page that Bora Ertung sent me does show a change on my machine -- from about 192ms to about 360-some between the 2006-06-16-04 and 2006-06-17-04 builds from the 1.8.0.x branch.

The relevant checkin window is http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-06-16+00&maxdate=2006-06-17+10&cvsroot=%2Fcvsroot

The problem is that nothing in that range jumps out as at all interesting to me except the version number change itself.

Furthermore, all trunk builds I've tested (including the one right before 1.8 branched off) show times similar to those for the 2006-06-17-04 (and to Firefox 1.5.0.5).

Not only that, but I set up a testcase along those lines at http://landfill.mozilla.org/ryl/XMLHttpRequest.html and I'm NOT seeing a slowdown on that between the two builds.

So if I had to guess, I'd guess that something server-side in that first testcase is doing things differently in the two cases.  I _did_ try setting general.useragent.override, and just having a different UA string is not the problem.  So I'm not sure what the problem is.

Comment 27

[ReleaseEngineer]

That is very weird to me as well. We used various operating systems with various servlet containers on various machines and we get the same problem on all configurations.

Comment 28

[ReleaseEngineer]

One thing caught my eye in your test  at http://landfill.mozilla.org/ryl/XMLHttpRequest.html. do you actually post something and get the result from 'lamepost.cgi'? Because our test case actually goes to a real servlet and the 'postmepostmepostmepostmepostmepostmepostme' is read from the stream and sent back to the browser. Our test case actually processes the post and replies. That may be the missing link Boris.

Comment 29

[Martijn Wargers (dead)]

The problem is that it is very hard to guess what is going on, a testcase or an url that shows the problem would be much appreciated.
Is it possible that one of the Mozilla people can view the web application to see if he can view the performance regression?

Comment 30

[Boris Zbarsky [:bzbarsky]]

I've changed http://landfill.mozilla.org/ryl/XMLHttpRequest.html to use POST to a script that just reads in the data and echoes it back.  I also just figured out that the dates I came up with in comment 26 are bogus thanks to wget doing weird stuff; I'll try to find an updated regression window.

Comment 31

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  So the new regression range is 2006-06-25-04 to 2006-06-26-04 and that corresponds to http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-06-25+04&maxdate=2006-06-26+04&cvsroot=%2Fcvsroot

So looks like the issue is the checkin for bug 334142, which was just a backout of bug 137155.

Which would make sense -- the latency from sending two packets for a POST would immediately double the time it takes (which is about what I was seeing).

Comment 32

[ReleaseEngineer]

Bug 137155 says it is an enhancement for future?!!!

Kewl! we are doomed for real now.

Comment 33

[Boris Zbarsky [:bzbarsky]]

If you want to help, figure out what was causing bug 334142...

Comment 34

[ReleaseEngineer]

If you wask me, bug 334142 was fixed with no testcase. It is interesting, why backout a fix before findind exactly what was wrong with that Banking site? It would have been something else. 

Unfortunately, I have no way of knowing what went wrong with that banking site.

Still keep this bug unconfirmed?

Comment 35

[Boris Zbarsky [:bzbarsky]]

> Unfortunately, I have no way of knowing what went wrong with that banking site.

Yeah, that's our problem too.

Comment 36

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So this is really the same as bug 137155, it's just the performance aspect of it. So I'm marking it a dupe.

In any case, this isn't really a regression. What happened was that we fixed a bug that sped things up, but also broke a site, so we backed it out. So yes, we're slower than we were while the patch was in, but we're not slower than where we started.

Comment 37

[ReleaseEngineer]

That is fine. However, bug 334142 shows no real proof that banking site in fact got broken because of the performance fix you have introduced which was back out. With no real test case in hand and by depending only on someonebody's interactive opinion, a bug which has wrecked havoc to many is still laying in the browser. My realistic assumption whould have been to ask that person to investigate any scripts in the page or the backend server of that banking site to see if the problem is an isolated incident because of a would be another bug or not. It would also have been a misimplementation of some server site requrest processing code or a javascript code handling the form submission.

In any case, whatever the problem was, I believe was not handled well. And a very bad bug is still in the loose since firefox 1.5.0.5.

And I do not know why I had to write this whole comment. Damaged badly from the this bug, I just wanted to express my opion I guess.

Comment 38

[Boris Zbarsky [:bzbarsky]]

> bug 334142 shows no real proof

How much more proof than "it doesn't work, you back out the patch, it starts to work" do you need?

Sorry, but asking users to debug HTTP interactions just isn't feasible...

Note that the current situation is no worse off than, say, Firefox 1.5, by the way.

Comment 39

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I would not be opposed putting the patch back in if we can get someone from the bank in question to help us out with debugging why this doesn't work. But we need someone to contact that bank and get them to work with us. Bora, would you offer to do that?

Comment 40

[ReleaseEngineer]

I wouldnt mind contacting the bank but I am neither their customer nor Italian. Not to mention, I may be flagged as possible hacker(cracker) by some European regulation some of which my coutry is also deeply involved with (I have no idea what I am talking about but sorry paranoi wins here).

On the other hand, Ironically, there is not a bank name or URL given in the bug as well. It would make more sense to ask the reported(Eugenio) of the bug 334142 to contact the bank and ask if other people have had experienced that problem. And, Boris, If you ask me, it should not work that way.