![]() ![]() Looking further in /etc/hosts, Local itself modifies the file for local resolution, which is how we can use a ‘foo.local’ domain reference on localhost. If you hard-set the hostname to an IPv4 address 127.0.0.1, there is no call to DNS - and your DB queries should all be lightning fast as mine are now. So even ‘localhost’ goes through a DNS resolution, which takes time. The fix was to move the always present IPv4 and IPv6 loopback entries from the host into the DNS resolver, where they could be independently disabled. This of course caused problems when IPv4 was not installed. With Windows Vista, when IPv4 was uninstalled and IPv6 was enabled, a DNS query for an A (IPv4) address resulted in the IPv4 loopback (which came from the hosts file). I checked with a developer on the Windows team, and the actual answer is much more innocuous than the other answers to this postĪt some point in the future, as the world transitions from IPV4 to IPV6, IPV4 will be eventually be disabled/uninstalled by companies that want to simplfy network management in their environments. The reason for this goes back to Windows Vista, as explained by Sean Earp in this Serverfault thread: From there it will attempt to resolve from wherever the local system gets DNS - your local network, your ISP, etc.īut if you look in Windows 10 “C:\Windows\System32\drivers\etc\hosts”, the line is commented out! # localhost name resolution is handled within DNS itself. The first place it tries in Windows and *nix, including iOS, is /etc/hosts. Whenever a process sees a name, whether example.tld or localhost, it needs to do a DNS lookup to translate that to an IP Address. Here’s why changing ‘localhost’ in wp-config.php works. My gut tells me there’s some sort of “helpful” security feature that Windows (or an antivirus) is doing, for example, scanning each request lookup. Things that come to mind are external request, but also the possibility of the theme making AJAX requests to the local site.įor those of you that are experiencing this slowness, I’d be curious to know what you find when using your site with those two tools. I’ll also be sure to use the Network tab of either Google Chrome or Firefox and see if there are any big issues. This will give us a good breakdown at the slowness of all the things that WordPress goes through when generating a response. To get more information in a WordPress context, I’ll take a look at the request with Query Monitor installed. ![]() Are there lots of slow, client-side requests to third-party urls?.I’m not able to replicate this slowness on my Windows machine.Ī few things that I do when troubleshooting performance issues are ask myself these things:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |