I am able to get Selenium driving Starting ChromeDriver 2.23.409699 via browsermob-proxy-2.1.2 and can access the HAR data however the timings seem strange particularly with SSL sites.
For example the first fetch is made to the website itself, which as per the timings takes:
# 512ms from start the first request goes out to page:
Connect: 1,306ms
SSL: 1,293ms
Send: 1ms
Wait: 16ms
Receive: 6ms
Then # 576ms (64ms after page) a second request to referenced style sheet goes out:
However as far as i can tell, the timings overlap in that request #2 goes out whilst the page is still waiting to connect (SSL and connection). Graphing it below shows them overlapping.
Any ideas what i am doing wrong or misunderstanding?
To summarize your data:
you start the capture
there is one request at 512ms to the main HTML page
there is another request at 576 ms to the stylesheet. This happens before the first request has finished
It is unlikely that a SSL handshake takes a whole 1293 ms. http://www.semicomplete.com/blog/geekery/ssl-latency.html lists times from 68ms to 408 ms for the complete transaction, including handshake. The same for retrieving https://www.mozilla.org/en-US/about/:
As a guess, Google did something clever with Chrome again.
It starts the TCP+SSL handshake,
then starts downloading the main HTML.
At the same time the HTML arrives, it is parsed, and
as soon as a stylesheet reference is encountered, this is downloaded as well (before the end of the HTML transfer).
These need to happen in separate threads for this optimization to work, but it could well reduce web download time (which seems to be one of Chrome's main aims).
Related
Running a react app in dev mode on localhost:3000 is stalled out with the initial loading network calls not responding.
To my knowledge, I didn't change anything between when the app was working and now. I've tried resetting to a previous git commit during which I know the project was working but the behavior is the same.
I've tried building the project and navigating to the built project
I don't even know where to look to troubleshoot this problem.
First of all, as Icepickle pointed out, this is fine. It's less than 1/500 of a second... it's nothing. :)
If you are still curious, you can have a look at these terms their explanations from the Google Network Analysis Reference. Here is some related info:
Queueing. The browser queues requests when:
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
Stalled. The request could be stalled for any of the reasons described in Queueing.
I have an application where a user can upload a PDF using angular-file-upload.js
This library does not support file chunking: https://github.com/nervgh/angular-file-upload/issues/41
My elastic load balancer is configured to have an idle timeout of 10 seconds and other parts of the application depend on keeping this parameter.
The issue is if the file upload takes longer than 10 seconds the user receives a 504 Gateway Timeout in the browser and an error message. However, the file still reaches the server after some time.
How can I ignore or not show the user this 504 Gateway Timeout that comes from the ELB? Is there another way around this issue?
The issue you have is that an ELB is always going to close the connection unless it gets some traffic back from your server. See below from AWS docs. It's the same behaviour for an ALB or a Classic load balancer.
By default, Elastic Load Balancing sets the idle timeout to 60 seconds
for both connections. Therefore, if the instance doesn't send some
data at least every 60 seconds while the request is in flight, the
load balancer can close the connection. To ensure that lengthy
operations such as file uploads have time to complete, send at least 1
byte of data before each idle timeout period elapses, and increase the
length of the idle timeout period as needed.
So to get around this, you have two options:
Change the server processing to start sending some data back as soon as the connection is established, on an interval of less than 10 seconds.
Use another library for doing your uploads, or use vanilla javascript. There are plenty of examples out there, e.g. this one.
Edit: Third option
Thanks to #colde for making the valid point that you can simply work around your load balancer altogether. This has the added benefit of freeing up your server resources which get tied up with lengthy uploads. In our implementation of this we used pre-signed urls to securely achieve this.
The OPTION/POST Request is failing inconsistently with a console Error as err_timed_out. We get the issue inconsistently, it's only observed sometimes. Otherwise the request gets proper response from the back end. When it's timing out, the request doesn't even reach the server.
I have done some research on the stuff and found that due to maximum 6 connections to a resource restrictions it may wait for getting a connection released. But, I don't see any other requests pending ,all the other requests were completed.
In the timeline I can always see that it stalled for 20.00 seconds. Most of the time the time is same. But, it only shows that its been stalled for some time nothing else in the timeline.
The status of the request shows failed ERR_Connection_Timed_Out. Please help.
The Network Timing
Console Error
I've seen this issue when I use an authenticated proxy server and usually a refresh of the page fixes it.
Are you using an authenticated proxy server where you are seeing this behavior? Have you tried on a pc with direct access (i.e. without proxy) to the Internet?
I've got the same problem when I choose another ISP. I thought I would have only to put my new ID and password, but it wasn't the case.
I have an ADSL modem with a dry loop.
All others services were fine (DNS resolution, IP telephony, FTP, etc).
I did a lot of tests (disable firewall, try some others navigator, try under Linux, modem default factory, etc) none of those tests were successful.
To resolve the problem ERR_TIMED_OUT, I had to adjust the MTU and MRU values. I put 1458 rather than 1492, which is the default value.
It works for me. Maybe some ISPs use different values. Good luck.
I have a fairly big application which went over a major overhaul.
The newer version uses lot of JSONP calls and I notice 500 server errors. Nothing is logged in the logs section to determine the error cause. It happens on JS, png and even jersey (servlets) too.
Searching SO and groups suggested that these errors are common during deployment. But it happens even after hours after deployment.
BTW, the application has become slightly bigger and it even causes deadline exception while starting few instances in few rare cases. Sometimes, it starts & serves within 6-10secs. Sometimes it goes to more than 75secs thereby causing a timeout for the similar request. I see the same behavior for warmup requests too. Nothing custom is loaded during app warmup.
I feel like you should be seeing the errors in your logs. Are you exceeding quotas or having deadline errors? Perhaps you have an error in your error handler like your file cannot be found, or the path to the error handler overlaps with another static file route?
To troubleshoot, I would implement custom error pages so you could determine the actual error code. I'm assuming Python since you never specified what language you are using. Add the following to your app.yaml and create static html pages that will give the recipient some idea of what's going on and then report back with your findings:
error_handlers:
- file: default_error.html
- error_code: over_quota
file: over_quota.html
- error_code: dos_api_denial
file: dos_api_denial.html
- error_code: timeout
file: timeout.html
If you already have custom error handlers, can you provide some of your app.yaml so we can help you?
Some 500s are not logged in your application logs. They are failures at the front-end of GAE. If, for some reason, you have a spike in requests and new instances of your application cannot be started fast enough to serve those requests, your client may see 500s even though those 500s do not appear in your application's logs. GAE team is working to provide visibility into those front-end logs.
I just saw this myself... I was researching some logs of visitors who only loaded half of the graphics files on a page. I tried clicking on the same link on a blog that they did to get to our site. In my case, I saw a 500 error in the chrome browser developer console for a js file. Yet when I looked at the GAE logs it said it served the file correctly with a 200 status. That js file loads other images which were not. In my case, it was an https request.
It is really important for us to know our customer experience (obviously). I wanted to let you know that this problem is still occurring. Just having it show up in the logs would be great, even attach a warm-up error to it or something so we know it is an unavoidable artefact of a complex server system (totally understandable). I just need to know if I should be adding instances or something else. This error did not wait for 60 seconds, maybe 5 to 10 seconds. It is like the round trip for SSL handshaking failed in the middle but the logs showed it as success.
So can I increase any timeout for the handshake or is that done on the browser side?
In the app I work on, we have an "export from highrise" feature that produces a .csv file.
Sometimes (depending on the things we need exported) the request takes a long time (7-10 minutes). Everything work fine (as far as I can tell) server side but my client's browser (he tried safari, chrome and firefox) doesn't get a response. Aka the browser just stays there with the loading animation indefinitely (well we gave up after 45 minutes).
On my machine everything works fine on all browsers. Based on the logs I have/put in place, everything goes as plan, the task ends the output is sent, but he gets no response.
Any idea is welcome, I have no idea where to look next.
EDIT: I did what #ceejayoz suggested but the problem persists, the browser doesn't receive a response, it just sits there waiting even though the file is generated correctly.
I'd have the export generate server-side, and have the user-facing page refresh or check via AJAX every 15-30 seconds to see if the export is complete. Once completed, redirect them to the file.