So messen Sie die Latenz in sieben Minuten richtig

Team kreativer Menschen, die an Schreibtischen in einem modernen Büro arbeiten

Für die richtige Messung der Latenz sind qualitativ hochwertige Daten erforderlich. Der Global CEO Outlook 2016 von KPMG (Link befindet sich außerhalb von ibm.com) ergab, dass 84 % der CEOs über die Qualität der Daten besorgt sind, auf die sie ihre Entscheidungen stützen, und das liegt daran, dass Daten oft irreführend sein können.

Der Unterschied zwischen Unternehmen, denen ihre Daten wichtig sind, und solchen, denen sie es nicht sind, ist enorm. MIT-Forscher haben herausgefunden (Link befindet sich außerhalb von ibm.com), dass Unternehmen, die einen datengesteuerten Ansatz im Design verfolgen, eine um 5–6 % höhere Leistung erzielen, als aufgrund ihrer sonstigen Investitionen und ihres Einsatzes von Informationstechnologie zu erwarten wäre. Schon dieser Aspekt zeigt, wie wichtig das Verständnis von Latenz für den Geschäftserfolg ist.

In nur sieben Minuten erfahren Sie alles, was Sie über das Messen von Latenz wissen müssen:

  • So messen Sie die Latenz
  • Warum es wichtig ist, sie richtig zu messen
  • Häufige Fallstricke bei der Betrachtung Ihrer Latenzdaten
  • Die Bedeutung von sofortigem Feedback
  • Warum ungesampelte Daten notwendig sind

Was versteht man unter Latenz?

Dictionary.com (Link befindet sich außerhalb von ibm.com) definiert Latenz als „die Zeit der Verzögerung, in der eine Komponente eines Hardwaresystems darauf wartet, dass eine Aktion von einer anderen Komponente ausgeführt wird“. Einfacher ausgedrückt bedeutet es die Zeitspanne zwischen dem Aufruf einer Funktion und ihrer tatsächlichen Ausführung. Latenz ist in allen Systemen vorhanden. Selbst wenn wir ein perfektes System hätten, was es nicht gibt, wäre es bereits in dem Maß latent, in dem die Elektronen im Computer brauchen, um die Transistoren von „ein“ auf „aus“ oder umgekehrt zu schalten.

Bei kleinen Vorgängen spielt Latenz keine große Rolle, aber bei Millionen von Vorgängen kommen ebenso viele Latenzen zusammen und das summiert sich sehr schnell. Latenz wird nicht durch Arbeitseinheiten und Zeit definiert, sondern dadurch, wie sie sich verhält. Überwachungstools melden, wie lange es vom Start einer Funktion bis zum Ende der Funktion dauert.

Latenzzeiten können erhebliche Auswirkungen auf Ihr Unternehmen haben. Zum Beispiel (Link befindet sich außerhalb von ibm.com): „Wenn es um mobile Geschwindigkeit geht, ist jede Sekunde wichtig – mit jeder weiteren Sekunde, die das Laden einer mobilen Seite dauert, können die Konversionen um bis zu 20 % sinken.“

Häufige Fallstricke bei der Betrachtung Ihrer Latenzdaten

Latenz folgt fast nie einer normalen Gauß- oder Poisson-Verteilung. Selbst wenn Ihre Latenz einer dieser Verteilungen folgt, sind Durchschnittswerte, Mediane und sogar Standardabweichungen aufgrund der Art und Weise, wie Latenz beobachtet wird, nutzlos. Wenn Sie beispielsweise die Seitenaufbauten messen, können99,999999999999 % dieser Ladevorgänge schlechter sein als Ihr Durchschnitt. Das ist mit ein Grund dafür, dass zufällige Stichproben bei Latenz zu ungenauen Daten führen – dazu später mehr.

An diesem Punkt fragen Sie sich wahrscheinlich, wie wir Latenzen sinnvoll beschreiben können, wenn wir keine Standardabweichung verwenden? Die Antwort ist, dass wir uns Perzentile und Maximalwerte ansehen müssen. Die meisten Leute denken sich: okay, wenn ich mir P95 anschaue, verstehe ich den „häufigsten Fall“. Das Problem bei dieser Methode ist, dass P95 all die schlechten Dinge ausblendet. Gil Tene, CTO von Azul Systems, sagt: „Es ist ein ,Marketing-System'. Irgendjemand wird getäuscht.“

Nehmen wir zum Beispiel diese Grafik:

Wenn Sie sich dieses Diagramm ansehen, können Sie deutlich erkennen, warum der Median und der Durchschnitt keine wirkliche Bedeutung haben, da sie nicht den Problembereich zeigen. Wenn Sie sehen, wie das 95. Perzentil links nach oben schnellt, denken Sie, den Kern des Problems zu erkennen. Das stimmt aber natürlich nicht. Wenn Sie untersuchen, warum Ihr Programm ein Problem hatte, übersehen Sie die schlimmsten 5 % des Geschehens. Um einen solchen Anstieg zu erzielen, müssen die obersten 5 % der Daten deutlich schlechter sein.

Sehen Sie sich nun dasselbe Diagramm an, das auch das 99,99. Perzentil zeigt:

Diese rote Linie ist das 95. Perzentil, während die grüne Linie das 99,99. Perzentil darstellt. Wie Sie deutlich sehen können, zeigt das 95. Perzentil nur 2 von 22 Ihrer Probleme und warum Sie das gesamte Spektrum Ihrer Daten betrachten müssen.

Viele mögen denken, dass die letzten 5 % der Daten keine so große Bedeutung haben. Sicher, es könnte einfach ein Neustart einer virtuellen Maschine (VM), eine Störung n Ihrem System oder ähnliches sein,aber indem Sie es ignorieren, sagen Sie, dass es einfach nicht passiert, obwohl es eines der wichtigsten Dinge sein könnte, auf die Sie sich konzentrieren sollten.

Gil Tene stellt gerne die kühne Behauptung auf: „Der wichtigste Indikator, den Sie niemals loswerden sollten, ist der Maximalwert. Das ist kein Rauschen, das ist das Signal. Der Rest ist Datenrauschen.“ Obwohl das Maximum in der Tat ein großartiger Einzelfall in einem System mit großem Umfang ist, ist es oft nicht praktisch, nur den Maximalfall zu verfolgen. Kein System ist perfekt, und es kommt durchaus zu Problemen. In einem groß angelegten praktischen System ist es oft eine gute Möglichkeit, das Entwicklungsteam ausschließlich durch die Verfolgung des Maximalfalls zu überlasten.

Wenn Sie sich das 99,99. Perzentil ansehen, sehen Sie, was mit der großen Mehrheit Ihrer Kunden passiert, und alle dort auftretenden Spitzenwerte deuten auf tatsächliche Probleme hin, während Spitzenwerte im Maximalbereich möglicherweise nur eine vorübergehende Störung in Ihrem System darstellen. Wenn sich Ihre DevOps-Teams auf diese kleinen Probleme konzentrieren, tun sie dies mit hohen Opportunitätskosten, da sie nicht an größeren Problemen arbeiten können.

Es ist wichtig zu beachten: Wenn Ihr 99,99. Perzentil und Ihr Maximum sehr nahe beieinander liegen – und beide sprunghaft ansteigen –, ist dies ein großartiges Signal dafür, dass es sich um ein Problem handelt, an dem Ihr Team arbeiten sollte. Insofern hat Gil zwar Recht, dass das Maximum ein starkes Signal ist, aber er irrt sich, wenn er sagt, dass der Rest der Daten nur Rauschen ist. Wie Sie in dieser Grafik sehen können, stimmen unser 99,99. Perzentil und das Maximum aus unserem vorherigen Beispiel genau überein. Das ist ein deutliches Zeichen dafür, dass es sich bei dem, was Sie sehen, um einen echten Fehler und nicht nur um eine vorübergehende Störung handelt:

Mittelwertbildung von Perzentilen: Wie die Vorberechnung zu Fehlmessungen der Latenz führt

Eine noch schlimmere Falle, in die Menschen tappen, als nur auf das 95. Perzentil zu schauen, besteht darin, nicht zu erkennen, dass ihre Perzentile gemittelt sind. Die Ermittlung von Durchschnittswerten von Perzentilen ist statistisch unsinnig. Es nimmt dem, was man betrachtet, jegliche Bedeutung. Wir haben bereits gezeigt, dass Durchschnittswerte bei der Betrachtung von Latenzzeiten nicht gut sind, und wenn Sie durchschnittliche Perzentile betrachten, sind Sie einfach wieder bei Null. Viele Softwareprogramme mitteln Ihre Perzentile. Nehmen Sie zum Beispiel dieses Grafana-Diagramm:

Unabhängig davon, ob Sie es vorher bemerkt haben oder nicht, sind alle Perzentile in diesem Diagramm durchschnittlich. Das steht genau dort im Hauptbuch der x-Achse. Fast alle Überwachungsdienste berechnen den Durchschnitt Ihrer Perzentile. Dank der Vorberechnung ist dies Realität. Wenn Ihr Überwachungsdienst Ihre Daten aufnimmt, berechnet er das Perzentil der Daten für diese Minute.

Wenn Sie sich dann Ihr 95. Perzentil ansehen, zeigt es Ihnen einen Durchschnitt aus all Ihren Perzentilen. Diese Abkürzung für „Ihr Wohlergehen“, um Ihren Service zu beschleunigen, führt in Wirklichkeit dazu, dass Ihren Daten jede statistische Signifikanz entzogen wird.

Warum Sie ungesampelte Daten benötigen, um die Latenz korrekt zu messen

Unabhängig davon, ob Sie es wissen oder nicht, produzieren Überwachungstools, die an der Datenerfassung beteiligt sind, gemittelte Daten. Nahezu jedes Überwachungstool erfasst seine Daten anhand von Stichproben. Nehmen wir Datadog als Beispiel: Es kommt zu einem großen Datenverlust. Wenn Sie ihnen 3 Millionen Punkte in einer Minute senden, werden sie nicht alle verbraucht. Stattdessen werden die Punkte nach dem Zufallsprinzip ausgewählt und dann zu einem Punkt pro Minute zusammengefasst.

Sie benötigen ungesampelte Daten, um Ihre Latenz zu verstehen. Es liegt in der Natur der Sache, dass man bei Stichprobendaten nicht auf die vollständige Verteilung zugreifen kann. Ihr Maximalwert ist nicht Ihr tatsächlicher Maximalwert, und Ihr globaler Perzentilwert ist keine genaue Darstellung der Realität.

Nutzen Sie die IBM Instana Software, um die Latenz effizient zu messen

Wenn man Daten stichprobenartig auswertet, lässt man Daten aus. Nehmen wir beispielsweise an, dass in einer Minute 10.000 Vorgänge ausgeführt werden, die jeweils 2 Datenpunkte an Ihr Überwachungssystem senden. Angenommen, Sie haben einen Fehler in Ihrem System und einer dieser Datenpunkte zeigt diesen Fehler bei 10.000 Vorgängen. Ihr Überwachungssystem hat nur eine Chance von 1/20.000, diesen Fehler als Datenpunkt auszuwählen, den es Ihnen als Maximum anzeigt.

Wenn Sie es lange genug laufen lassen, wird der Datenpunkt irgendwann auftauchen, aber dadurch sieht es wie ein sporadischer Edge-Case aus, obwohl es einem Ihrer Kunden jede Minute passiert. Wenn Sie keine Daten samplen und eine dieser Spitzen haben, wird sie deutlich in Ihrem 99,99. Perzentil angezeigt, und Ihr Maximum wird in der Nähe davon angezeigt, was signalisiert, dass Sie einen Fehler in Ihrem Programm haben. Wenn Sie jedoch Stichproben aus Ihren Daten ziehen, werden diese nicht so häufig auftauchen, was bedeutet, dass Sie sie nicht als Fehler, sondern als Problem wahrnehmen. Dieses Ergebnis bedeutet, dass Ihr Entwicklungsteam die Bedeutung nicht erkennen wird.

Lassen Sie sich nicht von Ihrem Überwachungstool täuschen, Sie wissen, was mit Ihrer Latenz passiert. Eines der Hauptmerkmale der IBM Instana™ Software ist ihre Fähigkeit, die Latenz effizient zu messen. Die IBM Instana-Software nutzt fortschrittliche Analyse und maschinelles Lernen (ML), um Latenzprobleme automatisch in Echtzeit zu erkennen, sodass Entwickler und IT-Teams die Ursache von Leistungsproblemen schnell identifizieren und Korrekturmaßnahmen ergreifen können, bevor sie sich auf die Benutzer auswirken.

Wählen Sie ein Tool, das keine Stichprobendaten bereitstellt. Wählen Sie ein Tool, das keine Mittelwerte über die globalen Perzentile ermittelt.

Weiterführende Lösungen
IBM Cloud Pak for Network Automation 

IBM Cloud Pak for Network Automation ist ein Cloud Pak, das die Automatisierung und Orchestrierung von Netzwerkinfrastrukturbetrieben ermöglicht.

Cloud Pak Automation erkunden
Netzwerklösungen

Cloud-Netzwerklösungen von IBM bieten eine leistungsstarke Konnektivität, um Ihre Apps und Ihr Unternehmen zu unterstützen.

Cloud-Netzwerklösungen erkunden
Netzwerk-Support-Services

Konsolidieren Sie die Rechenzentrumsunterstützung mit IBM Technology Lifecycle Services für Cloud-Netzwerke und mehr.

Cloud-Netzwerkdienste
Machen Sie den nächsten Schritt

Stärken Sie Ihr Unternehmen mit modernsten DNS-Management- und Cloud-Netzwerklösungen. Verbessern Sie die Zuverlässigkeit Ihrer Anwendungen und optimieren Sie die Netzwerkleistung mit den führenden Diensten von IBM.

Cloud-Netzwerklösungen erkunden Managed DNS Services entdecken