We have had a angularJS application, then we've updated our FE to angular7.1 and now every request in chrome is stalled for about 450ms, both static files and data requests.
There isn't such an issue on local version of an application
Firefox and IE don't block requests.
Do you have a any idea about this? Thanks.
Was tested with Cache-Control: no-store, no-cache, must-revalidate
Was tested with only one request at a time
Was tested with and w/o proxy
(can't post images)
Old app chrome behavior:
AngularJS behavior image
New app chrome behavior:
Angular7 behavior image
New app IE behavior:
Angular7 IE behavior image
UPDATE:
Even first request is stalled.
Waterfall looks like this:
Waterfall
Please read the following information in the link that #JonathanHamel posted:
A request being queued indicates that:
The request was postponed by the rendering engine because it's considered lower priority than critical resources (such as scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that's about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache entries (typically very quick.)
Additionally, Stalled/Blocking is the time the request spent waiting before it could be sent. It can be waiting for any of the reasons described for Queueing. Additionally, this time is inclusive of any time spent in proxy negotiation.
Please tell us which of these case might apply to you.
Related
My tech stack includes react on UI and spring boot on server.
All the other api requests made to server work just fine but one request that has response of an array with a million records has this issue.
The response size is about 15mb and the request shows 200 as status code.
But the timing tab of the request shows this flag - Caution: request is not finished yet.
As long as this flag stays, the application becomes unresponsive.
On doing my research on this issue, I found that this means that chrome is expecting some more data as response.
Is there something to be mentioned in the response header to resolve this issue?
As the application becomes unresponsive, how can this be terminated by a button click? I added axios cancel token but that cancels the request only if its pending and not when 200 comes as status.
I'm using Etags in the response headers for dynamic resources, and my client is sending future requests for the same resource with the If-None-Match header.
The client and server are interacting perfectly, and I get 304 responses if the data was not modified. I can see this on the nginx logs on my server, and the browser network tab on Firefox. However, when i log the exact same response from the whatwg-fetch response status, I'm getting 200.
Although react doesn't re-render if there is not diff in the data, all the processing till that point (dispatching actions, running custom data manipulation etc) are being executed, which is consuming too much memory.
I'm using react-boilerplate, which is internally whatwg-fetch, and too far out to make a U-turn and start using xhrHttpRequests, which apparently don't have this problem from the scant resources I found in other parts of the web.
Please help; I can attach logs and notes if need be. Thanks :)
I'm using Ionic platform for my mobile application. Using angular
$http for sending requests to server.
Intermittently when Mobile app tries to access server $http goes to it's errorCallback with response status -1 only no other
data.
When I check log on server, not able to see any hit.
I've changed timeout of application to 2 minutes using interceptors.
I have used chrome debugger but it won't show anything apart from
request it forms, shows nothing in response and preview columns.
I got that in Ionic we use pre-flight to check if server is alive
before sending actual request. But it's for CORS; we have enabled
CORS on server and thats why app is working good since last 15 days.
Thought of using network packet tracer tool but if call not logged on
server no use of it. as Status -1 says $http aborted the request.
My Question is why it's aborting when I click once and do send
when I click same button again.
Please me help to figure out an issue.
After lots of debugging and surfing over internet for issue.
I guess that an issue was like mobile app sending pre-flight messages and so $http aborting the request and even some time Server played a culprit here how will tell you;
We have server hosted on AWS in where we had Load balancer in different zone and actual API server is in different zone. After changing them to same zone ask, production people to test now they are not getting this issue.
The another reason was we were using unstable mobile networks to test.
If any one have any thing else on this please let me know.
I've implemented a basic chat app with PubNub in Angular and noticed that the response time after a publish is really long.
Testing the process on the tutorial sample does the same thing -
TTFB is 2.2 minutes.
Request URL: http://ps5.pubnub.com/subscribe/demo/chat/0/14358752049456252?uuid=6cf0c87b-6379-430c-98d4-8c9be14b1db9
Response: [[],"14358752049456252"]
Anyone have an idea why this trip is taking so long?
PubNub Response Time Too Long
You are likely seeing the long-poll keep-alive socket return data in that time span from within Chrome's Developer Console Network Tab. This is normal. In fact it is a very good thing which provides network efficiencies and timeliness of delivery of realtime data to your browser and devices.
In the APP Engine API, it is mentioned that, if the request comes with "Accept-Encoding" set, then it will automatically compress the response.
But when I look at the request, the header is not there. but at the browser, it is set. when I try to explicitly set the header(with JQuery ajax function), there is a message:
Refused to set unsafe header "Accept-Encoding"
But this situation is not occurring when working in local host - request has the "Accept-Encoding" header. this happens only after publishing. but not allowing to set the "Accept-Encoding" explicitly happens always.
I searched everywhere, but couldn't find a explanation to the problem. It would be really helpful if someone can explain...
You have two different problems:
App Engine does not compress reply. GAE uses a number of factors to determine if response needs to be compressed. It takes content type and user agent into account when deciding. See the answer by Nick Johnson (from GAE team).
jQuery refuses to set "Accept-Encoding" header. Note that this is a jQuery issue and has nothing to do with GAE. See this: Is it possible to force jQuery to make AJAX calls for URLs with gzip/deflate enabled?
I have a similar problem as in the HTTPRequest header, "Accept-Encoding" is null. As GAE has explained it looks for Accept-Encoding and User-Agent headers, if it wants to compress. but in my case there is no way the GAE can recognize whether to compress.
From the browser, then header is set, but in the request header, it is not.