Latenzmesswerte

Auf dieser Seite werden die von Cloud Spanner bereitgestellten Latenzmesswerte beschrieben. Wenn in Ihrer Anwendung eine hohe Latenz auftritt, können Sie das Problem mithilfe dieser Messwerte diagnostizieren und beheben.

Sie können diese Messwerte in der Google Cloud Console und in der Cloud Monitoring-Konsole aufrufen. Auf der Seite „Monitoring“ in der Google Cloud Console werden zwei Latenzmesswerte angezeigt. Der erste ist für Latenz und der zweite für Latenz nach Transaktionstyp.

Latenz

Die Latenzmesswerte für Spanner messen die Zeit, die Spanner für das Verarbeiten der Lesefunktionen (Read, StreamingRead, ExecuteSql, StreamingExecuteSql, ExecuteBatchDml) oder Schreiben (Commit) benötigt hat. Wählen Sie „Lesen/Schreiben“ aus, um Messwerte für beide anzuzeigen. Der Messwert erfasst die tatsächlich verstrichene Zeit und nicht die CPU-Zeit, die Spanner verwendet hat.

Diese Latenzmesswerte umfassen keine Latenzen, die außerhalb von Spanner auftreten, z. B. die Netzwerklatenz und die Latenz in Ihrer Anwendungsebene. Wenn Sie andere Arten von Latenz messen möchten, können Sie Cloud Monitoring verwenden, um Ihre Anwendung mit benutzerdefinierten Messwerten zu instrumentieren.

Sie können sich die Latenzmesswerte in der Google Cloud Console und in der Cloud Monitoring-Konsole ansehen. Sie können sich kombinierte Latenzmesswerte ansehen, die sowohl Lese- als auch Schreibfunktionen enthalten, oder separate Messwerte für Lese- und Schreibvorgänge.

Basierend auf der Latenz jeder Anfrage gruppiert Spanner die Anfragen in Perzentile. Sie können sich Latenzmesswerte für die Latenz des 50. Perzentils und des 99. Perzentils ansehen:

  • Latenz des 50. Perzentils: Die maximale Latenz in Sekunden für die schnellsten 50 % aller Anfragen. Wenn die Latenz des 50. Perzentils beispielsweise 0,5 Sekunden beträgt, hat Spanner 50% der Anfragen in weniger als 0,5 Sekunden verarbeitet.

    Dieser Messwert wird manchmal als mittlere Latenz bezeichnet.

  • Latenz des 99. Perzentils: Die maximale Latenz in Sekunden für die schnellsten 99 % der Anfragen. Wenn beispielsweise die Latenz des 99. Perzentils 2 Sekunden beträgt, hat Spanner 99% der Anfragen in weniger als 2 Sekunden verarbeitet.

Latenz und Vorgänge pro Sekunde

Wenn eine Instanz eine kleine Anzahl von Anfragen innerhalb eines bestimmten Zeitraums verarbeitet, sind die Latenzen des 50. und 99. Perzentils in diesem Zeitraum keine aussagekräftigen Indikatoren für die Gesamtleistung der Instanz. Unter diesen Bedingungen kann eine sehr kleine Anzahl von Ausreißern die Latenzmesswerte drastisch ändern.

Angenommen, eine Instanz verarbeitet 100 Anfragen innerhalb einer Stunde. In diesem Fall entspricht die Latenz des 99. Perzentils für die Instanz in dieser Stunde der Zeit, die für die Verarbeitung der langsamsten Anfrage benötigt wurde. Eine Latenzmessung auf Basis einer einzelnen Anfrage ist nicht aussagekräftig.

Latenz nach Transaktionstyp

Die Latenz nach Transaktionstypmesswerten für Spanner misst und zeigt die Zeit an, die Spanner für die Verarbeitung einer Transaktion benötigt hat. Sie können Messwerte für nicht schreibgeschützte Transaktionen und schreibgeschützte Transaktionen aufrufen. Der Transaktionstyp „Lese-Schreib“ umfasst alle Lese-Schreib-Transaktionen und der schreibgeschützte Transaktionstyp umfasst alle schreibgeschützten Transaktionen sowie einzelne Lesemethoden.

Wie die Latenzmesswerte gruppieren diese Diagramme die Daten in Perzentilen. Sie können den Messwert „Latenz nach Transaktionstyp“ für die Latenz des 50. Perzentils und des 99. Perzentils aufrufen.

Ein bedeutender Unterschied zwischen dem Messwert „Latenz“ und dem Messwert „Latenz nach Transaktionstyp“ besteht darin, dass Sie im Diagramm „Latenz nach Transaktionstyp“ die schreibgeschützten Transaktionstypen nach „Leader ist beteiligt“ oder „Kein Leader“ einbeziehen. Wenn Sie „Leader ist beteiligt“ auswählen, wird ein Diagramm mit Anfragen angezeigt, an denen der Leader beteiligt war. Wenn beispielsweise ein starker Lesevorgang von einem schreibgeschützten Replikat angefordert wird, wird das Leader geprüft, um sicherzustellen, dass das schreibgeschützte Replikat über die neuesten Daten verfügt. In diesem Fall hilft die Auswahl von "Leader ist beteiligt" bei der Bewertung der Gesamtzeit, die für die Verarbeitung der starken Lesetransaktion benötigt wurde. Wenn Sie „Kein Leader“ auswählen, werden im Diagramm Lesevorgänge angezeigt, an denen kein Leader beteiligt war. Wenn beispielsweise ein veralteter Lesevorgang mit einer Zeitstempelgrenze von mindestens 15 Sekunden von einem schreibgeschützten Replikat angefordert wird, liefert das schreibgeschützte Replikat möglicherweise den veralteten Lesevorgang, ohne dass der Leader einbezogen wird. Im Vergleich dazu können Lesevorgänge, an denen der Leader beteiligt ist, eine höhere Latenz haben. Sie können diese Diagramme verwenden, um den Latenzunterschied zwischen starken Lesevorgängen und veralteten Lesevorgängen zu bewerten. Beachten Sie, dass in einigen Fällen ein veralteter Lesevorgang auch von einem Leader bereitgestellt werden kann. In diesen Fällen werden die veralteten Lesevorgänge unter dem Diagramm „Leader beteiligt“ angezeigt.

Bei Lese-Schreib-Transaktionen ist der Leader immer an der Transaktion beteiligt. Die im Diagramm angezeigten Daten enthalten daher immer die Zeit, die erforderlich ist, damit die Anfrage den Leader erreicht und eine Antwort erhält.

Latenzprobleme diagnostizieren

In den folgenden Abschnitten wird beschrieben, wie Sie einige häufig auftretende Probleme diagnostizieren, die zu einer hohen End-to-End-Latenz Ihrer Anwendung führen können.

Mit der Google Cloud Console können Sie sich kurz mit den Latenzmesswerten einer Instanz vertraut machen. Wenn Sie die Messwerte genauer untersuchen und nach Korrelationen zwischen Latenz und anderen Messwerten durchsuchen möchten, verwenden Sie die Cloud Monitoring Console.

Hohe Gesamtlatenz, niedrige Spanner-Latenz

Wenn die Latenz Ihrer Anwendung höher als erwartet ist, die Latenzmesswerte für Spanner jedoch erheblich niedriger sind als die End-to-End-Latenz, liegt möglicherweise ein Problem im Anwendungscode vor. Wenn Ihre Anwendung ein Leistungsproblem hat, das dazu führt, dass einige Codepfade langsam sind, kann sich die Gesamtwartezeit für jede Anfrage erhöhen.

Sie können dieses Problem beheben, indem Sie bei Ihrer Anwendung einen Leistungstest durchführen, um Codepfade zu identifizieren, die langsamer als erwartet sind.

Sie können auch den Code auskommentieren, der mit Spanner kommuniziert, und dann die Gesamtlatenz noch einmal messen. Wenn sich die Gesamtlatenz nicht stark ändert, ist Spanner wahrscheinlich nicht die Ursache für die hohe Latenz.

Hohe Gesamtlatenz, hohe Spanner-Latenz

Wenn die Latenz Ihrer Anwendung höher als erwartet ist und die Latenzmesswerte für Spanner ebenfalls hoch sind, gibt es mehrere mögliche Ursachen:

  • Ihre Instanz benötigt mehr Rechenkapazität. Wenn Ihre Instanz nicht genügend CPU-Ressourcen hat und die CPU-Auslastung das empfohlene Maximum überschreitet, kann Spanner Ihre Anfragen möglicherweise nicht schnell und effizient verarbeiten.

  • Einige Ihrer Abfragen verursachen eine hohe CPU-Auslastung. Wenn Ihre Abfragen keine Spanner-Features nutzen, die die Effizienz verbessern (z. B. Abfrageparameter und sekundäre Indexe) oder eine große Anzahl von Joins oder anderen CPU-intensiven Vorgängen enthalten, können die Abfragen einen großen Teil der CPU-Ressourcen für Ihre Instanz verwenden.

Verwenden Sie die Cloud Monitoring Console, um nach einer Korrelation zwischen hoher CPU-Auslastung und hoher Latenz zu suchen. Überprüfen Sie außerdem die Abfragestatistik für die Instanz, um alle CPU-intensiven Abfragen im selben Zeitraum zu ermitteln.

Wenn die CPU-Auslastung und die Latenzzeit gleichzeitig hoch sind, können Sie das Problem so beheben:

Nächste Schritte