I am trying to make sense of the Chrome Developer Tools when I run performence tests on my websites. If you select Network on the tools meny it will look like this:
Then if I select the performance file I will have this information:
My question is this:
What is the meaning of DNS Lookup, Connecting, Sending, Waiting and Receving? What is happening between the server, network and browser at each stage?
On the first image, the red line reads "Load event fired" and the blue one reads "DOMContent event fired". What is the meaning of this and why is it the DOMContent event is fired after all the content has been loaded?
Answering part II:
The Blue line (DOM content loaded event): It happens when the browser finished parsing the main document.
The Red line (Load event): It happens when the browser finished retrieving all the resources required by the main document.
After the red line: Here you will see loading of asynchronous and cached resources required by the main document and by other resources.
I'm not sure if this is a good fit for SO as this is a network question more than a programming question but I'll answer the parts I can...
DNS Lookup
When you connect to a website, it has to look up the IP from the DNS. For example, your computer will contact a DNS asking if it knows where "google.com" is. If it does, it'll give you an IP. If it doesn't, it'll either give you the IP of another DNS or it will contact that DNS itself (I'm not sure which implementation applies where) until eventually you end up with the IP of the host you're looking for.
Connecting
Time it takes to connect with that IP. I'm not sure of the details here.
Sending
After connecting, you send the request to the server. It can be a request to view a page or submit data or anything.
Waiting
After sending your request, you wait for the server to respond to it. It can be busy or might take a while to process whatever you requested.
Receiving
Once the server has processed your request, it'll send data back to you.
Here is a description by Google:
https://developers.google.com/web/tools/chrome-devtools/network/reference
Related
I am trying to configure some hardware using the ip address: 192.168.1.251. For some insane reason Firefox keeps forcing it to https://192.168.1.251.
The fact is (a) the address is never on the internet; (b) in this case it is the only other machine; and (c) I have no control over how the hardware does its job any way. So what genius decided that they know better and I can’t connect using plain old http?
The question is how can I tell Firefox to just shut up and do as it’s told? I have already tried browser.urlbar.autoFill and network.stricttransportsecurity.preloadlist and neither of them works.
This might be because at some point a server at this address responded with an HSTS header.
Click on the icon to the left of the URL in the address bar, then in the dialog click clear cookies and site data. Then confirm in the dialog that appears.
The timing section of the Firefox Network Monitor documentation, "Blocked" is explained as:
Time spent in a queue waiting for a network connection.
The browser imposes a limit on the number of simultaneous connections that can be made to a single server. In Firefox this defaults to 6
Is the limit on the number connections the only limitation? Or is the browser blocked waiting to get a connection from the OS count as blocked too?
In a fresh browser, on a first connection, before any other connection is made (so the limit should not apply here), I get blocked for 195 ms.
Is this the browser waiting for the OS? Was does "Blocked" mean here?
We changed the Firefox setting (about:config) 'network.http.max-persistent-connections-per-server' to 64 and the blocks went away. We changed it back to 6. We changed our design/development method to a more 'asynchronous' loading method so as not to have a large number simultaneous connections. The blocks were mostly loading a lot of png flags for locale settings.
I have a server that takes several seconds to respond, which allowed me to cross-reference the firefox measurement with a wireshark trace. I see that the first SYN is sent out immediately. The end of the "Blocked" time corresponds to when the Server Hello comes back.
I couldn't relate the end of "TLS setup" to any wireshark packet. It extends a few seconds belong the last data that is exchanged on the initial TLS connection.
Bottom line: it doesn't look like the time spent in "Blocked" and "TLS setup" is very reliable, at least in some cases.
My setup has a TLS reverse proxy that forwards the connection with SNI. I'm not sure if that might be related.
Time spent in a queue waiting for a network connection.
The browser imposes a limit on the number of simultaneous connections
that can be made to a single server. In Firefox this defaults to 6,
but can be changed using the
network.http.max-persistent-connections-per-server preference. If all
connections are in use, the browser can't download more resources
until a connection is released.
Source : https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor
It's very clear that the browser fixes the limit to 6 concurrent connections per server (domains/IP), the OS question is not very relevent.
In my case both waiting for network connection and DNS lookup times were pretty high, up to 2 seconds each, caused significant page load times if the page was loaded for the first time. Firefox was freshly installed without addons and just started with no other opened tabs. I tried on both Ubuntu 18.04 LTS and Ubuntu 19.04 with the same results. Although my ISP doesn't provide support, my router assignes IPv6 addresses. As it turned out the problem was the IPv6 broken network, which forced Firefox to fall back to IPv4 (of course after some time(time-out)). After I turned off the IPv6 support in Linux the requests speeded up significantly.
Here is a relavant discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=1452028
I encountered this error whilst using an Angular 9 'dist' deployment. I discovered that the error appeared because I was trying to access an unreachable API, according to the specified IP address and port.
Therefore to solve it, I just have to reference a valid and accessible API.
I'm trying to improve my azure mobile app performance.
However just calling the web app root url (azure static "This mobile app is up and running" page) with fiddler can take up to 7 sec.
I'm lost how it's even possible and what I can and should do to improve it.
My current plan is B1 and "Always On" is On.
UPDATE
The long time where a combination of two things:
Long DNS Lookup
Log warmup of the mobile app after a deployment
Both issues can be addressed differently. For the warmup, check #arianhall answer below (which I marked as correct). For DNS lookup it can be many things. In my case the problem was broader: my ipv6 dns server was bad and it wouldn't switch to ipv4 after some timeout.
ps: and it's not a ping I was doing but a webpage load as azurewebsites don't accept ping anyway.
Irrespective of whether AlwaysOn is on or not, the first request after a deployment results in a "wake-up" cost. To fix that, you need to warm up the site. This blog post will describe how to do this: http://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/
On our router we have the primary DNS set to a local IP, which is running Windows Server 2008 and the built in DNS server. We use this to resolve domains to local servers, if the domain is not founds locally we have forwarders set up to query external name servers.
The secondary DNS on the router is set to our ISP's primary DNS, incase the local DNS server is down.
The mac clients in our office pick up the DNS servers correctly from the router but it seems very random as to what DNS server it uses. For example, a local site would load up but some of the images would not. If I hard coded my DNS address to be the local DNS server everything would work fine.
So my question is, when would a mac client use the secondary DNS server? I though it'd only use it if the primary DNS was unavailable?
Thanks!
The general idea of a secondary DNS server was that in case the primary DNS server doesn't reply (e.g. it is offline, unreachable, restarting, etc.), the system can fall back to a secondary one, so it won't be unable to resolve DNS names during that time. Doesn't reply means "no reply at all", it will not ask the secondary when the primary one said that a name is unknown. Answering that a name is unknown is a reply.
The problem here is that DNS uses UDP and UDP is connectionless. So if a DNS server is offline, the system won't notice that other by not receiving a reply from it. As an UDP packet may as well get lost and the round-trip time (RTT) is unknown, it will have to resend the request a couple of times, every time waiting for several seconds, before it finally gets to the conclusion that this server is dead. This means it can take up to an entire minute and above to resolve a DNS name if the first DNS server dies.
As that seems unacceptable, different operating system developed different strategies to handle this in a better way. As both DNS servers are supposed to deliver the same result for the same domain (if not, your setup is actually flawed as the secondary should be a 1-to-1 replacement for the primary one), it shouldn't matter which one is being used. Some systems may send a request to the primary one but if no reply comes back within a few seconds, they don't resend to it but first try the secondary one (then they resend to the primary one and so on). Some may also query both at once, make the faster one win and then keep using that one for a while (until they start another race to see if it is still the faster one). Some may also prefer the primary one but do some kind of load balancing and switch to the secondary one if more than a certain amount of queries are currently pending on the primary one. Some will just alternate between them as a poor man's load balancing. All of this is actually allowed.
In your case, though, I'm afraid something is wrong with your primary server as by default, macOS will only use the primary one. If it constantly falls back to the secondary one, it may consider the primary one to be too slow. Every time that happens, the secondary server becomes the primary one, see this older knowlebase article. This cnet article explained how this can be disabled but I'm not sure this is still possible in current systems. I wasn't able to find any reference on this but IIRC from the very back of my head, Apple once mentioned on a WWDC that they are now more aggressive at DNS querying and may even try to contact multiple DNS servers at once with the fastest one winning in some cases but I might be wrong on this (maybe this was iOS only or so).
I googled this article which explains newer MacOS DNS search order. And this one which explains how to tweak it to obtain results that you desire.
Though the general idea is that it was never intended (in any OS) that first server is the one used and the second one is a backup. ( Even on windows, if first server for some reason doesn't answers very quickly, the second one will be queried.) It's wiser to regard server query order as unspecified.
I perform a process using selenium (i.e open pages, click on links,..) and I want to get the network traffic only of the last page and only on error. That is, when opening a moving to a new page the "network log" on the selenium host needs to be empty. If an error occurs on the page, I call captureNetworkTraffic and get the last headers.
According to captureNetworkTraffic's documentation this is the only function that clears the logs. The problem is that it get's the logs and I want to reduce network traffic to the selenium host. Is there a way to tell selenium to clear the logs w/o actually getting them?