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.
Related
I am using Axios instance in a React app to fetch data from GET requests. Backend server is deployed on Heroku(Professional Dyno) and written in Django REST framework. Database is deployed on AWS.
On postman, APIs are giving response in around 2-3 seconds:
Postman Screenshot
But in the react app, response time is around 25-30 seconds.
React app response time Screenshot
Please note that I am calling around 10 different APIs in a single page. Is this affecting the response times?
The problem is, your request got blocked for 18 seconds. When you are executing multiple heavy requests, it's definitely possible that this requests takes some time to be even executed. If you want to check whether this is the reason for it, you could just comment out the other requests an examine what happens.
An interesting request on what blocked means can be found here.
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.
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.
We have a web application (UI wrapped in CEF + WPF) where we make a JavaScript POST request to the server. The POST request only has query string parameters and no request body. The server takes up to 5 minutes to process and send a small response back. Even when the server sends the response back (lets say 4 minutes), the request is still shown as pending in the Inspector (and success callback is not executed). Only after 8-10 minutes the response is shown as complete (and success callback is executed).
When we check the time distribution of the finished request call, it says that everything finished in 4 minutes which is very strange. This behavior is not happening in Google chrome browser. Any advise on what could be going wrong.