Was bedeutet Chrome Network Timings wirklich und was wirkt sich auf jede Timing-Länge aus?

8

Ich habe Chrome-Entwicklungstools das Timing der Ressourcennetzwerke untersucht, um solche Anfragen zu erkennen muss verbessert werden. In der vorherigen Verknüpfung gibt es eine Definition für jedes Timing, aber ich verstehe nicht, welche Prozesse hinter den Kulissen durchgeführt werden, die die Länge des Zeitraums beeinflussen.

Unten sind 3 verschiedene Bilder und hier ist mein Verständnis von dem, was vor sich geht, korrigiere mich bitte, wenn ich falsch liege.

Stillstand: Warum gibt es Timings, bei denen die Anfrage für 1,17 Sekunden blockiert wird, während andere weniger verbrauchen?

Anfrage gesendet : Es ist die Zeit, die unsere Anfrage brauchte, um den Server zu erreichen

TTFB : Die Zeit hat gedauert, bis der Server mit dem ersten Datenbyte antwortet

Inhalt herunterladen : Die Zeit, bis die gesamte Antwort den Kunden erreicht hat

Danke

    
Lothre1 06.07.2015, 07:40
quelle

1 Antwort

8

Netzwerk ist ein Bereich, in dem die Dinge sehr unterschiedlich sind. Es gibt viele verschiedene Zahlen, die mit diesen spielen und sie variieren zwischen verschiedenen Orten und sogar dem gleichen Ort mit verschiedenen Arten von Inhalten.

Hier finden Sie weitere Details zu den Bereichen, mit denen Sie mehr Verständnis benötigen:

Angehalten: Dies hängt davon ab, was sonst noch im Netzwerk-Stack passiert. Eine Sache konnte überhaupt nicht angehalten werden, während andere Anfragen blockiert werden konnten, weil 6 Verbindungen zum selben Ort bereits offen waren. Es gibt mehr Gründe für das Abwürgen, aber das maximale Verbindungslimit ist ein einfacher Weg, um zu erklären, warum es auftreten kann.

Der blockierte Zustand bedeutet, dass wir die Anfrage gerade nicht senden können, wenn aus irgendeinem Grund warten muss. Im Allgemeinen ist dies keine große Sache. Wenn Sie es häufig sehen und Sie im HTTP2-Protokoll nicht sind, sollten Sie die Anzahl der Ressourcen, die von einem bestimmten Standort abgerufen werden, minimieren. Wenn Sie sich auf HTTP2 befinden, sollten Sie sich nicht zu viele Gedanken darüber machen, da es zahlreiche Anfragen anders behandelt.

Schauen Sie sich um und sehen Sie, wie viele Anfragen an eine einzelne Domain gesendet werden. Sie können das Filterfeld verwenden, um die Ansicht zu verkleinern. Wenn viele Anfragen an dieselbe Domain gesendet werden, wird wahrscheinlich das Verbindungslimit erreicht. Domain sharting ist eine Methode, um dies mit HTTP 1.1 zu handhaben, aber mit HTTP 2 ist es ein Anti-Pattern und beeinträchtigt die Performance.

Wenn Sie das maximale Verbindungslimit nicht erreichen, ist das Problem nuancierter und erfordert einen praktischeren Debugging-Ansatz, um herauszufinden, was vor sich geht.

Gesendete Anforderung: Dies ist nicht die Zeit, um den Server zu erreichen, also die Zeit bis zum ersten Byte. Alle gesendeten Anfragen bedeuten, dass die Anfrage gesendet wurde und der Netzwerkstapel X Zeit benötigt, um sie auszuführen.

Nichts, was Sie tun können, um dies zu beschleunigen, es ist eher für informative und interne Debugging-Zwecke.

Zeit bis zum ersten Byte (TTFB): Dies ist die Gesamtzeit für die gesendete Anforderung, um zum Ziel zu gelangen, dann für das Ziel, um die Anfrage zu verarbeiten, und schließlich für die Antwort, um das Ziel zu durchlaufen Netzwerke zurück zum Client.

Ein hoher TTFB zeigt eines von zwei Problemen. Die erste ist eine schlechte Netzwerkverbindung zwischen dem Client und dem Server. Daten sind also langsam, um den Server zu erreichen und zurück zu bekommen. Die zweite Ursache ist ein langsamer Server, der die Anfrage verarbeitet. Dies liegt entweder daran, dass die Hardware schwach ist oder die Anwendung langsam läuft. Oder beide Probleme können gleichzeitig auftreten.

Um einen hohen TTFB zu adressieren, schneiden Sie zuerst so viel Netzwerk wie möglich aus. Idealerweise hosten Sie die Anwendung lokal auf einer virtuellen Maschine mit geringen Ressourcen und prüfen Sie, ob noch ein großer TTFB vorhanden ist. Wenn dies der Fall ist, muss die Anwendung für die Reaktionsgeschwindigkeit optimiert werden. Wenn der TTFB lokal sehr niedrig ist, dann sind die Netzwerke zwischen Ihrem Client und dem Server das Problem. Es gibt verschiedene Möglichkeiten, damit umzugehen, auf die ich nicht eingehen werde, da es sich um ein Fachgebiet für sich selbst handelt. Forschungsnetzwerk-Optimierung, und versuchen Sie sogar, Hosts zu verschieben und zu sehen, ob das Netzwerk Ihrer Server-Provider das Problem ist.

Denken Sie daran, dass der gesamte Server-Stack hier ins Spiel kommt. Wenn also nginx oder apache schlecht konfiguriert sind oder Ihre Datenbank lange braucht, um zu antworten, oder wenn Ihr Cache Probleme hat, können diese Verzögerungen verursachen. Sie sind auch lokal schwer zu erkennen, da der lokale Server in der Konfiguration vom Remote-Stack abweichen kann.

Inhalt herunterladen: Dies ist die Gesamtzeit von der TTFB-Auflösung für den Client, um den Rest des Inhalts vom Server zu erhalten. Dies sollte kurz sein, es sei denn, Sie laden eine große Datei herunter. Sie sollten sich die Größe der Datei, die Bedingungen des Netzwerks ansehen und dann darüber entscheiden, wie lange dies dauern sollte.

    
Garbee 06.07.2015, 14:18
quelle