Opis stanu „Stalled” w dzienniku sieci Chrome

Mam następujący log sieciowy w chrome:

Nie rozumiem jednej rzeczy: jaka jest różnica między wypełnionymi szarymi słupkami a przezroczystymi szarymi słupkami.

Google podaje podział tych pól w sekcji Ocena wydajności sieci w dokumentacji DevTools.

Fragment z taktowania sieci zasobów :

Utknięcie / Blokowanie

Czas oczekiwania, zanim żądanie zostało wysłane. Ten czas obejmuje czas spędzony na negocjacjach proxy. Ponadto ten czas będzie obejmował sytuacje, w których przeglądarka czeka, aż już ustanowione połączenie stanie się dostępne do ponownego użycia, przestrzegając maksymalnej liczby sześciu połączeń TCP na źródło w przeglądarce Chrome .

(Jeśli zapomnisz, Chrome ma link „Wyjaśnienie” w podpowiedzi i pod panelem „Czas”).

Zasadniczo głównym powodem, dla którego to zobaczysz, jest to, że Chrome będzie pobierać tylko 6 plików na serwer na raz, a inne żądania będą wstrzymywane, dopóki gniazdo połączenia nie będzie dostępne.

Niekoniecznie jest to coś, co wymaga naprawy, ale jednym ze sposobów uniknięcia stanu wstrzymania jest dystrybucja plików na wiele nazw domen i / lub serwerów, pamiętając o CORS , jeśli ma to zastosowanie do twoich potrzeb, jednak HTTP2 jest prawdopodobnie lepszą opcją iść naprzód. Pakowanie zasobów (takie jak konkatenacja JS i CSS) może również pomóc w zmniejszeniu liczby blokowanych połączeń.

DevTools: [sieć] wyjaśniają puste słupki poprzedzające żądanie

Po dokładniejszym zbadaniu stwierdziliśmy, że nie ma znaczącej różnicy między naszymi zakresami wstrzymanymi i kolejkowymi. Oba są obliczane na podstawie delta innych znaczników czasu, a nie dostarczane z netstack lub renderer.

---

Obecnie, jeśli czekamy na udostępnienie gniazda:

• Nazywamy to utknięciem, jeśli doszło do negocjacji proxy
• Nazywamy to kolejkowaniem, jeśli nie jest wymagana żadna praca proxy / ssl.

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

Pochodzi z oficjalnej strony Chome-devtools i pomaga. Tutaj cytuję:

• Kolejkowanie Jeśli żądanie jest umieszczane w kolejce, oznacza to, że:
  • Żądanie zostało odroczone przez silnik renderujący, ponieważ ma niższy priorytet niż krytyczne zasoby (takie jak skrypty / style). Dzieje się tak często w przypadku obrazów.
  • Żądanie zostało zawieszone, aby czekać na niedostępne gniazdo TCP, które ma zostać zwolnione.
  • Żądanie zostało wstrzymane, ponieważ przeglądarka zezwala tylko na sześć połączeń TCP na źródło HTTP 1. Czas spędzony na tworzeniu wpisów w pamięci podręcznej dysku (zazwyczaj bardzo szybki).
• Stalled / Blocking Czas oczekiwania na żądanie przed wysłaniem. Może czekać na którykolwiek z powodów opisanych dla kolejkowania. Dodatkowo czas ten obejmuje czas spędzony na negocjacjach proxy.

W moim przypadku strona wysyła wiele żądań z różnymi parametrami, gdy była otwarta. Więc większość z nich jest „zatrzymywana”. Kolejne żądania wysłane natychmiast zostają wstrzymane. Lepiej byłoby unikać niepotrzebnych próśb (być leniwym ...).

Ponieważ przyjeżdża tu wiele osób debugujących swoją powolną stronę internetową, chciałbym poinformować o mojej sprawie, której żadne z wyjaśnień google nie pomogło rozwiązać. Moje ogromne czasy opóźnień (czasami 1 minuta) były spowodowane tym, że Apache działający w systemie Windows miał zbyt mało wątków roboczych do obsługi połączeń, dlatego były one w kolejce.

Może to dotyczyć Ciebie, jeśli dziennik Apache zawiera następującą notatkę:

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

Ten problem został rozwiązany w httpd.conf serwera Apache. Odkomentuj: dołącz conf / extra / httpd-mpm.conf

I edytuj plik httpd-mpm.conf

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

Zauważ, że możesz nie potrzebować 2000 wątków lub możesz potrzebować więcej. Rok 2000 był w moim przypadku OK.