Long Receiving Time Only in FF not IE - javascript

I have had this unusual problem with my Spring rest server for a couple of months where performance with Firefox (52.0.1 32-bit and 64-bit) is much much worse than with Internet Explorer (9-11) when receiving large amounts of JSON data.
The server that is hosting my service is a Windows Server Enterprise 2007 SP2.
If I could, I would update it, but that is not allowable.
To further define my problem, making a request to an endpoint to retrieve the JSON data results in an almost immediate response in Firefox, but it is stuck in "Receiving" for sometimes in upwards of 90 seconds. Internet Explorer typically is done in 2-3 seconds. (See photo below of network output from FF)
I have a feeling that this may be a server problem because previous to this service being hosted on this server, it was being hosted from a linux vm while we were deving and testing the service. During that time the response time with FF and IE were both the same and very quick (in fact the same response time as IE has now).
I tagged javascript in this not to tag spam, but because when the data comes back it does go through some rigorous transformations in the JS and I'm not sure if that is contributing to the problem. (This is doubtful though just because if IE can handle it FF should being that Mozilla deved JS)
My question is: Would you say this problem is related to the server, JS implementation, or something else? and what might I do to solve this problem?

Related

Firefox performance profiler | Not showing useful information for ~5 secs

In my Angular JS app, when hitting an HTTP request I am observing lags of ~5 secs. This happens when large data is sent in the request. More the input data, more the lag.
Additionally, this is observed only in Firefox. All other browsers don't show any lag at all.
I can confirm that the request is being sent in Asynchronous mode only.
In fact, I can see that request is successfully completed in the Network tabs, however, the callback function doesn't get called for ~5 secs.
There is no such lag observed in Google Chrome, IE or Safari.
I tried using the Performance tab under Firefox Debugging tools to analyze what is causing my webpage to hang.
This is even more confusing, as I see a big gap between Minor GC and Parse HTML option.
What does this large gap mean?
At the moment, the only thing I am doing is removing 1-2 modules of the code base and expect the problem to go away.
Is there any better way to debug this?

Possible causes for long blocking xhr on mac chrome?

I have a consistent extremely long (2min+) blocking call on mac/chrome. The same set of steps work just fine on other operating systems or browsers. (And even some other macs.) The site isn't super chatty, and there aren't any other requests that take anywhere over 2 seconds.
The blocking PUT call almost always follows a DELETE call to a different url. (Same server.) According to my console logs, the server actually receives and returns the results of the PUT call very quickly. So Chrome thinks it is blocked but it is actually already processed!
Any ideas?
Following up on this post: Chrome and Firefox CORS AJAX calls get aborted on some Mac machines
This mac had a DISABLED Sophos antivirus on the machine. Uninstalling it completely fixed this issue.
ARGGGGG.
Hopefully someone else finds this post and is able to spend less than the hours we spent on it.

What could be stopping AJAX from returning?

I'm trying to troubleshoot a problem on a client's machine for our website. We're using an ajax call to get information on a page to select additional parameters. Our callback function has a block of code for reading when the ajax coming back is an error or is correct. For every other computer that we've tested this with, the ajax comes back. However, for a particular client, we're seeing the ajax come back with the error message, meaning the response never got there successfully or that it's corrupted or broken.
Does anyone know how this would happen? The client is using IE 8 and I've tested IE 8, IE 9, IE 10, and Chrome and all of those work on my computers.
EDIT: As of now, we don't have access to the system and the network that would be causing the error. They are trying to see if they can accept everything from our domain and see if that fixes it, but right now, I can't put Fiddler on their computer.
I've seen any amount of random behaviour caused by virus scanners and so-called network security products. Try adding an exception for your site to any security software your client is running.
The other thing to do is to use Wireshark, Fiddler, etc. to see what's actually happening at the network level.

Internet Explorer stuttering requests

For a special project I chose to write my very own tiny web server which is actually quite easy with the .Net Framework (HttpListener class).
Everything was working beautifully until yesterday when I started to test with Internet Explorer.
My server kept crashing on any ie request ! I finally managed to figure the reason out : ie litterally stutters ! (well at least ie7 and ie8, I've not tried other versions yet).
The problem never occurs with FireFox nor Chrome nor Opera.
To be more specific, I'm using dynamic javascript insertion in the web page to get around the same origin policy in a cross-domain call scenario. This script generates a request to my tiny server. Let's say the request built is :
http://localhost:8081/myService?p1=A,p2=B,p3=C,p4=D,p5=E
With FFox, Chrome or Opera, my server indeed receives a single request from the browser :
http://localhost:8081/myService?p1=A,p2=B,p3=C,p4=D,p5=E
with ie, my server receives a random amount of partial requests like :
http://localhost:8081/myService?p1=A,
http://localhost:8081/myService?p1=A,p2=B,
http://localhost:8081/myService?p1=A,p2=B,p3=C,
http://localhost:8081/myService?p1=A,p2=B,p3=C,p4=D,
(and in fact a lot of them since I have 20 parameters or so...)
and finally :
http://localhost:8081/myService?p1=A,p2=B,p3=C,p4=D,p5=E
This is bascically not big deal as my logic is able to handle the lacking parameters situation. The problem is that each incomplete request actually closes the connection (error 1229). That was crashing the server which was trying to answer to each request. The fix was easy but I still don't like the fact that the server is flooded with those intermediate "unanswerable" and thus unuseful requests.
(Moreover, the request sometimes looks like :
http://localhost:8081/myService?p1=A,p2=B,p3=C,?p1=A,p2=B,p3=C,p4=D,p5=E
!!! )
I traced the javascript : the generation function is called only once (whatever browser) so this really sounds like an ie issue.
Does anyone have an idea to prevent this behaviour from ie ?

Node.js/Socket.io not returning results in IE, using a secure connection

I have successfully implemented socket.io, node.js and express to server realtime json data to all browsers except IE (testing on 9) using a secure connection. This worked fine everywhere until I moved it behind https. From the server console output, it shows that an event is received when called from IE:
xhr-polling received data packet 5:::{"name":"lookup_place","args":
[{"place":"Berlin"}]}
However, no response is given and the next 4 lines shown in the console are:
clearing poll timeout
xhr-polling writing 8::
set close timeout for client 27081179790885432
xhr-polling closed due to exceeded duration
When the same is done from FF or Chrome, the line "xhr-polling writing 8::" is appended with the correct response, for example:
xhr-polling writing 5:::{"name":"place_results","args":[{"a":
[{"identifier":"52156","value":"Monschau, 52156"},
{"identifier":"67590","value":"Monsheim, 67590"},
{"identifier":"04617","value":"Monstab, 04617"}]}]}
I am using node.js version 0.4.10, socket.io version 0.7.7 and express version 2.4.3. The same scripts worked perfectly fine in IE 7-9 without an https/ssl/secure connection.
Any help would be greatly appreciated in discovering why no response is delivered in IE but works fine in all others.
Might be a bug. I would advice you to fill an issue at Socket.io's github issue page. Then the authors will also receive an email and probably respond pretty fast.

Categories