Chrome lento per risolvere / etc / hosts su macOS / OS X


9

I nostri sviluppatori usano Docker o VirtualBox (con Vagrant) per testare il loro codice localmente (e il problema si verifica con entrambi). Per facilitare ciò, modifichiamo / etc / hosts per puntare all'indirizzo IP corretto. Per esempio,

local.test.company.com 10.200.10.1

Alcuni dei nostri sviluppatori sono su Linux e altri su macOS Sierra (10.12.3). Su Mac, le richieste a local.test.company.com in Chrome (e altri browser) spesso richiedono molto tempo (fino a un minuto o più) per essere risolte. (Il problema non si verifica su Ubuntu Linux.) Durante questo periodo, l'icona di caricamento nella scheda è l'icona grigia che gira a sinistra. Non appena si trasforma nell'icona blu che gira a destra, termina molto rapidamente. Il tempo di caricamento lento può essere un vero problema per i nostri sviluppatori che spesso aggiornano il sito durante lo sviluppo.

Sulla base di questa domanda, sembra che Chrome stia impiegando un minuto intero per risolvere il sito. Questo non ha senso per me: un sito in / etc / hosts dovrebbe risolversi immediatamente. Alcuni sviluppatori possono riprodurre questo comportamento in modo molto coerente. Altri lo vedono a intermittenza o non lo vedono affatto, e non sono stato in grado di capire il perché.

Perché le richieste a local.test.company.com richiedono molto tempo per essere risolte in un browser Web?

Oppure, cosa posso fare per "eseguire il debug" di questo problema e capire cosa sta impiegando così tanto tempo?


Note aggiuntive

  • Il comportamento continua a verificarsi con Chrome in "modalità di navigazione in incognito" con "disabilita cache" attivata.
  • ping risolve local.test.company.com immediatamente.

Risposte:


9

Ho avuto lo stesso problema in Chrome 64.0.3282.167 su macOS High Sierra (10.13.3) e questa risposta StackOverflow l'ha risolto per me:

https://stackoverflow.com/a/10200111/318359

Citazione:

Metti tutte le voci del file hosts per localhost in una riga in questo modo:

127.0.0.1 localhost myproject.dev myotherproject.dev 
::1 localhost

1
Grazie grazie! Lo sopporto da così tanto tempo! C'è anche una risposta interessante in merito agli .localindirizzi che vengono controllati con bonjour prima del DNS: stackoverflow.com/a/17982964/2778502
jeff-h

2

Hai provato a eseguire dtruss su Chrome per vedere cosa sta facendo quando si blocca?

https://opensourcehacker.com/2011/12/02/osx-strace-equivalent-dtruss-seeing-inside-applications-what-they-do-and-why-they-hang/


Ottimo consiglio! Ci proverò e vedrò come va.
mkasberg,

Puoi anche provare a usare "strumenti" che danno una migliore visualizzazione.
Mooyah,

1
Sebbene la tua risposta sia corretta al 100%, potrebbe anche diventare inutile al 100% se quel link viene spostato, modificato, unito in un altro o il sito principale scompare ... :-( Pertanto, modifica la tua risposta e copia il relativo passi dal link alla tua risposta, garantendo così la tua risposta per il 100% della vita di questo sito! ;-) Puoi sempre lasciare il link in fondo alla tua risposta come fonte per il tuo materiale ...
Paperino

0

Alla fine l'ho capito. A quanto pare, Chrome non si risolve necessariamente mentre il cerchio gira a sinistra. Il cerchio su Chrome gira a sinistra durante il caricamento dei dati e a destra durante il download dei dati .

L'ho capito eseguendo il debug dell'applicazione PHP in esecuzione su Chrome. PHP risponde a una richiesta di Chrome, il cerchio in Chrome continua a girare a sinistra fino alla prima printistruzione in PHP . Cioè, fino a quando il server non invia il primo byte di dati al client.

Quindi, in sintesi, questo non è stato affatto un problema con la risoluzione DNS. Il DNS andava bene, la nostra applicazione web semplicemente non stava inviando indietro i dati così velocemente come pensavamo (sia a causa della sospensione nel debugger o per altri motivi).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.