Comprensione dello stato "Stalled" del registro di rete di Chrome

Ho un seguente registro di rete in Chrome:

Non capisco nulla: qual è la differenza tra barre grigie piene e barre grigie trasparenti.

Google fornisce una suddivisione di questi campi nella sezione Valutazione delle prestazioni della rete della loro documentazione DevTools.

Estratto dalla tempistica della rete di risorse :

In fase di stallo / Blocco

Tempo trascorso dall'attesa prima che potesse essere inviata. Questo tempo è comprensivo di qualsiasi tempo trascorso nella negoziazione per procura. Inoltre, questa volta includerà quando il browser è in attesa che una connessione già stabilita diventi disponibile per il riutilizzo, obbedendo al massimo sei connessioni TCP di Chrome per regola di origine.

(Se dimentichi, Chrome ha un link "Spiegazione" nella descrizione comandi al passaggio del mouse e sotto il pannello "Temporizzazione".)

Fondamentalmente, il motivo principale che vedrai questo è perché Chrome scaricherà solo 6 file per server alla volta e altre richieste verranno bloccate fino a quando non sarà disponibile uno slot di connessione.

Questo non è necessariamente qualcosa che deve essere risolto, ma un modo per evitare lo stato di stallo sarebbe quello di distribuire i file su più nomi di dominio e / o server, tenendo presente CORS se applicabile alle proprie esigenze, tuttavia HTTP2 è probabilmente un'opzione migliore andando avanti. Il raggruppamento di risorse (come la concatenazione JS e CSS) può anche aiutare a ridurre la quantità di connessioni bloccate.

DevTools: [rete] spiega le barre vuote che precedono la richiesta

Esaminato ulteriormente e hanno identificato che non vi è alcuna differenza significativa tra i nostri intervalli di stallo e di accodamento. Entrambi sono calcolati dal delta di altri timestamp, piuttosto che forniti da netstack o renderer.

---

Attualmente, se stiamo aspettando che un socket diventi disponibile:

• lo chiameremo bloccato se si è verificata una negoziazione del proxy
• lo chiameremo in coda se non era richiesto alcun lavoro proxy / ssl.

https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing

Questo viene dal sito ufficiale di Chome-devtools e aiuta. Qui cito:

• Accodamento Se una richiesta viene messa in coda, indica che:
  • La richiesta è stata rinviata dal motore di rendering perché è considerata una priorità inferiore rispetto alle risorse critiche (come script / stili). Questo accade spesso con le immagini.
  • La richiesta è stata messa in attesa per attendere un socket TCP non disponibile che sta per essere liberato.
  • La richiesta è stata messa in attesa perché il browser consente solo sei connessioni TCP per origine su HTTP 1. Tempo impiegato per creare voci nella cache del disco (in genere molto veloce).
• Tempo di stallo / blocco della richiesta trascorsa in attesa prima di poter essere inviata. Può essere in attesa di uno dei motivi descritti per Accodamento. Inoltre, questo tempo è comprensivo di qualsiasi tempo trascorso nella negoziazione del proxy.

Il mio caso è che la pagina sta inviando più richieste con parametri diversi quando era aperta. Quindi la maggior parte viene "bloccata". Le seguenti richieste immediatamente inviate vengono "bloccate". Evitare richieste non necessarie sarebbe meglio (essere pigri ...).

Dato che molte persone arrivano qui eseguendo il debug del loro sito Web lento, vorrei informarti sul mio caso che nessuna delle spiegazioni di Google ha aiutato a risolvere. I miei enormi tempi di stallo (a volte 1 minuto) sono stati causati da Apache in esecuzione su Windows con troppi thread di lavoro per gestire le connessioni, quindi venivano messi in coda.

Questo può applicarsi a te se il tuo registro di Apache ha la seguente nota:

Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Questo problema è stato risolto in httpd.conf di Apache. Uncomment: include conf / extra / httpd-mpm.conf

E modifica httpd-mpm.conf

<IfModule mpm_winnt_module>
   ThreadLimit              2000
   ThreadsPerChild          2000
   MaxConnectionsPerChild   0
</IfModule>

Nota che potresti non aver bisogno di 2000 thread o di averne bisogno di più. Il 2000 andava bene per il mio caso.