Performance und Skalierbarkeit: Latenz, Durchsatz, Perzentile und Last

Zwei verschiedene Fragen: wie schnell und wie viel

Performance ist die Qualität, die zuerst genannt und am schlechtesten spezifiziert wird. Sie umfasst zwei verschiedene Fragen. Latenz fragt, wie lange eine Arbeitseinheit dauert: wie viele Millisekunden zwischen dem Tippen auf „Bezahlen“ und der Meldung „Zahlung akzeptiert“ liegen. Durchsatz fragt, wie viel Arbeit das System pro Zeiteinheit erledigt: 1200 Zahlungen pro Sekunde, 40.000 Bestellungen pro Stunde. Beide hängen zusammen, sind aber nicht austauschbar. Ein Reisebus, der 50 Menschen in 100 Minuten von London nach Oxford bringt, hat eine schlechtere Latenz und einen viel besseren Durchsatz als ein Sportwagen, der zwei Menschen in 60 Minuten befördert.

In Software zeigt sich dieselbe Spannung überall. Datenbank-Schreibvorgänge zu bündeln verbessert den Durchsatz, lässt aber jeden einzelnen Schreibvorgang auf seinen Stapel warten. Ein Cache verbessert beides für wiederholte Lesezugriffe, hilft aber nicht beim ersten. Eine gute Performance-Anforderung sagt deshalb, um welche Frage es geht, und nennt meist beides: „bei 1200 Zahlungen pro Sekunde (Durchsatz) werden 99 % innerhalb von 800 ms abgeschlossen (Latenz)“. ISO/IEC 25010 ordnet dies unter Leistungseffizienz als Zeitverhalten, Ressourcennutzung und Kapazität ein (Abschnitt 2.2).

Antwortzeit = Bedienzeit + Wartezeit

Wenn Sie die Latenz auf der Seite des Clients messen, erhalten Sie die Antwortzeit: alles, was zwischen dem Senden der Anfrage und dem Empfang der Antwort geschah. Es lohnt sich, sie in Teile zu zerlegen. Die Bedienzeit ist die Zeit, die eine Ressource tatsächlich an Ihrer Anfrage arbeitet: sie parst, die Abfrage ausführt, das Ergebnis aufbereitet. Die Wartezeit ist die Zeit, die Ihre Anfrage in einer Warteschlange verbringt, weil die Ressource mit der Anfrage eines anderen beschäftigt ist. Hinzu kommt die Netzwerk-Übertragungszeit, in beiden Richtungen.

Die Unterscheidung zählt, weil die beiden Teile auf unterschiedliche Mittel ansprechen. Die Bedienzeit sinkt, wenn Sie die Arbeit selbst billiger machen: ein besserer Index, eine kleinere Nutzlast, ein schnellerer Algorithmus. Die Wartezeit sinkt, wenn Sie Kapazität hinzufügen oder die Last senken, und sie ist bei einem ausgelasteten System oft viel größer als die Bedienzeit. Viele Untersuchungen einer „langsamen Datenbank“ enden mit der Entdeckung, dass jede Abfrage 5 ms dauert, aber 300 ms auf eine freie Verbindung im Pool wartet.

Perzentile: Warum Mittelwerte irreführen

Antwortzeiten sind nie eine einzelne Zahl; sie bilden eine Verteilung, und die ist fast immer schief. Die meisten Anfragen sind schnell, und eine Minderheit ist langsam, weil sie auf einen kalten Cache, eine Garbage-Collection-Pause, eine Sperre, eine Wiederholung oder einen überlasteten Nachbarn trifft. Das arithmetische Mittel vermischt beide Gruppen zu einem Wert, der niemanden beschreibt. Fachleute verwenden stattdessen Perzentile. Das 50. Perzentil (p50, der Median) ist der Wert, den die Hälfte der Anfragen unterbietet; p95 ist der Wert, den 95 % der Anfragen unterbieten; p99 und p99,9 beschreiben die langsamsten 1 % und 0,1 %.

Das langsame Ende der Verteilung heißt Tail, und es ist wichtiger, als es scheint. Die Benutzer im Tail sind oft Ihre besten Kunden: die mit den größten Warenkörben, der längsten Historie und den meisten Daten. Ein Benutzer, der 40 Ressourcen lädt, um eine Seite anzusehen, erlebt die langsamste dieser 40, nicht den Durchschnitt. Und die Wahrscheinlichkeit, dass eine Seite mit 40 Ressourcen mindestens eine p99-Anfrage trifft, beträgt 1 − 0,99⁴⁰ ≈ 33 %: Ein „seltenes“ 1-%-Ereignis betrifft ein Drittel der Seitenaufrufe.

# Why the mean misleads: 1,000 response times from one minute of traffic
import statistics

times_ms = [80] * 900 + [150] * 80 + [1200] * 15 + [4000] * 5

mean = statistics.mean(times_ms)
cuts = statistics.quantiles(times_ms, n=1000, method="inclusive")
p50, p95, p99, p999 = cuts[499], cuts[949], cuts[989], cuts[998]
print(f"mean {mean:.0f} ms, p50 {p50:.0f}, p95 {p95:.0f}, p99 {p99:.0f}, p99.9 {p999:.0f}")
# mean 122 ms, p50 80, p95 150, p99 1200, p99.9 4000

Tail-Latenz im großen Maßstab

Der Tail wird zum Hauptereignis in großen Systemen mit Fan-out, bei denen eine Benutzeranfrage in viele parallele Anfragen an andere Server aufgeteilt wird und die Antwort auf alle warten muss. Eine Suchmaschine, ein Social-Feed oder eine Empfehlungsseite befragt für jede Abfrage womöglich Dutzende oder Hunderte von Backend-Shards. Jeffrey Dean und Luiz André Barroso von Google haben das in The Tail at Scale (Communications of the ACM, 2013) analysiert.

Ihre Veranschaulichung ist einfach. Angenommen, jeder Server antwortet typischerweise in 10 ms, braucht aber für eine von 100 Anfragen 1 Sekunde. Eine Benutzeranfrage, die auf einen Server wartet, ist in 1 % der Fälle langsam. Eine Benutzeranfrage, die auf 100 solcher Server wartet, ist immer dann langsam, wenn irgendeiner von ihnen langsam ist: in 1 − 0,99¹⁰⁰ ≈ 63 % der Fälle. Ein seltenes Ereignis an einem Server wird für den Benutzer zum Normalfall. Dean und Barroso berichten Messungen aus einem Google-Service, bei dem die Latenz im 99. Perzentil für eine einzelne Leaf-Anfrage 10 ms betrug, das 99. Perzentil für das Warten auf alle Leaf-Anfragen aber 140 ms.

Weil sich nicht jede Quelle der Schwankung beseitigen lässt (geteilte Hardware, Hintergrundjobs, Garbage Collection, Netzwerk-Queues), plädieren sie für tail-tolerante Entwürfe, so wie fehlertolerante Entwürfe akzeptieren, dass Hardware ausfällt. Zu ihren Techniken gehören Hedged Requests (eine zweite Kopie an ein anderes Replikat senden, wenn die erste nicht innerhalb etwa der Zeit des 95. Perzentils geantwortet hat, und die zuerst eintreffende Antwort verwenden), verknüpfte Anfragen, die sich gegenseitig abbrechen, feiner granulierte Partitionen, die sich umverteilen lassen, das vorübergehende Ausschließen langsamer Maschinen und die Rückgabe eines ausreichend guten Ergebnisses, wenn die meisten, aber nicht alle Shards geantwortet haben. In einem von ihnen beschriebenen Benchmark senkte Hedging nach 10 ms die Latenz im 99,9. Perzentil von 1800 ms auf 74 ms, bei nur etwa 2 % mehr Anfragen.

Littles Gesetz: wie viele Anfragen gleichzeitig in Bearbeitung sind

Littles Gesetz, 1961 von John Little bewiesen, ist die nützlichste einzelne Formel der Kapazitätsplanung. Für jedes stabile System gilt: Die durchschnittliche Zahl der Elemente darin (L) ist gleich der durchschnittlichen Ankunftsrate (λ, Lambda) multipliziert mit der durchschnittlichen Verweildauer jedes Elements (W): L = λ × W. Es gilt unabhängig vom Ankunftsmuster oder der Reihenfolge der Bedienung, sofern das System stabil ist (im Mittel verlassen es so viele Elemente, wie ankommen) und Sie einheitliche Einheiten verwenden.

In Software ist L die Zahl der gleichzeitig laufenden Anfragen (die Nebenläufigkeit), λ die Anfragerate und W die Antwortzeit. Erhält ein Service 200 Anfragen pro Sekunde und verbringt jede 0,25 Sekunden darin, sind im Mittel jederzeit 200 × 0,25 = 50 Anfragen in Bearbeitung. Diese Zahl bestimmt Thread-Pools, Connection-Pools, Arbeitsspeicher und Lizenzanzahlen. Das Gesetz funktioniert auch rückwärts: Können Sie höchstens 50 Anfragen gleichzeitig halten und dauert jede 0,25 s, schaffen Sie dauerhaft nicht mehr als 50 ÷ 0,25 = 200 Anfragen pro Sekunde.

Auslastung und Warteschlangen: Warum Systeme von der Klippe stürzen

Auslastung (ρ, Rho) ist der Anteil der Zeit, in dem eine Ressource belegt ist. Ein Server, der 40 Anfragen pro Sekunde erhält, die jeweils 20 ms Bedienzeit brauchen, ist 40 × 0,020 = 0,8 der Zeit belegt: zu 80 % ausgelastet. Die Intuition sagt, eine zu 80 % belegte Ressource sollte nur wenig langsamer sein als eine zu 50 % belegte. Die Theorie der Warteschlangenbildung sagt etwas anderes, denn Anfragen treffen nicht gleichmäßig ein; sie ballen sich, und wenn sie sich ballen, warten die späteren.

Das einfachste Modell ist die M/M/1-Warteschlange: zufällige Ankünfte, zufällige Bedienzeiten und ein einzelner Server. Ihre mittlere Antwortzeit ist W = S ÷ (1 − ρ), wobei S die mittlere Bedienzeit ist. Bei 50 % Auslastung ist W = 2S. Bei 80 % ist W = 5S. Bei 90 % ist W = 10S. Bei 99 % ist W = 100S. Der Nenner schrumpft gegen null, wenn sich die Auslastung 100 % nähert, sodass die Antwortzeit unbegrenzt wächst. Reale Systeme sind nicht genau M/M/1, und Pools mit mehreren Servern verhalten sich bei gleicher Auslastung besser, aber die Form ist universell: flach, dann ein Knick, dann eine Klippe.

Die praktischen Lehren sind direkt. Planen Sie nicht, kritische Ressourcen nahe 100 % Belegung zu betreiben; lassen Sie Reserve, damit Lastspitzen Sie nicht über den Knick schieben. Beobachten Sie Auslastung und Queue-Länge gemeinsam (die USE-Methode von Brendan Gregg prüft für jede Ressource Auslastung, Sättigung und Fehler). Und denken Sie daran, dass die Klippe kleine Änderungen gefährlich macht: Bei 90 % Auslastung bringt Sie ein Anstieg des Traffics um nur etwa 6 % auf 95 % und verdoppelt die mittlere Antwortzeit. Kapitel 9 behandelt Queues, Backpressure und Kapazitätsplanung in Asynchronität, Queues und Backpressure.

Skalierbarkeit: Last, Elastizität, Scale-up und Scale-out

Skalierbarkeit ist die Fähigkeit, durch zusätzliche Ressourcen mehr Last zu bewältigen, idealerweise mit proportional wachsender Kapazität und ohne Neuentwurf. Sie bedeutet erst etwas, wenn Sie sagen, was „Last“ ist. Lastparameter unterscheiden sich von System zu System: Anfragen pro Sekunde bei einer API, gleichzeitige Verbindungen bei einem Chatdienst, das Verhältnis von Lese- zu Schreibzugriffen bei einem sozialen Netzwerk, das Datenvolumen bei einer Analyseplattform oder die Zahl der Follower des meistgefolgten Kontos bei einem Feed. Ein Skalierbarkeitsszenario nennt den Lastparameter, das Wachstum und die Antwort, die erhalten bleiben muss: „Wenn die täglichen Bestellungen von 50.000 auf 500.000 steigen, bleibt die p95-Latenz des Checkouts durch zusätzliche Instanzen unter 1,5 s, bei höchstens 20 % höheren Kosten pro Bestellung.“

Elastizität fügt die Zeit hinzu: die Fähigkeit, Kapazität automatisch hinzuzufügen und zu entfernen, wenn die Last steigt und fällt, sodass eine Ticketplattform für einen Vorverkauf wachsen und danach wieder schrumpfen kann. Sie ist ein großer Teil des wirtschaftlichen Arguments für Cloud-Plattformen. Es gibt zwei grundlegende Wege, Kapazität hinzuzufügen. Vertikale Skalierung (Scale-up) gibt einem Rechner mehr CPU, mehr Arbeitsspeicher oder schnelleren Speicher; sie ist einfach, erfordert keine Änderung an der Software und stößt an harte Grenzen und steigende Preise. Horizontale Skalierung (Scale-out) fügt weitere Rechner hinzu und verteilt die Arbeit; sie hat keine feste Obergrenze, verlangt aber, dass die Software dafür entworfen ist, mit zustandslosen Instanzen, Lastverteilung und partitionierten Daten. Kapitel 9 behandelt die Strategien ausführlich in Skalierungsstrategien: vertikal, horizontal und der Scale Cube.

Amdahls Gesetz: die Grenze der Parallelität

Mehr Prozessoren oder Knoten helfen nur bei Arbeit, die sich parallel erledigen lässt. Das Amdahlsche Gesetz, aus Gene Amdahls Aufsatz von 1967 über die Grenzen des parallelen Rechnens, erfasst das. Ist ein Anteil s der Arbeit seriell (er muss Schritt für Schritt erledigt werden) und lässt sich der Rest, 1 − s, perfekt auf N Prozessoren aufteilen, beträgt die bestmögliche Beschleunigung speed-up(N) = 1 ÷ (s + (1 − s) ÷ N). Wächst N unbegrenzt, nähert sich die Beschleunigung 1 ÷ s. Bei 10 % serieller Arbeit kann keine Zahl von Prozessoren den Job mehr als zehnmal schneller machen.

Das Universal Scalability Law

Amdahls Gesetz nimmt an, dass zusätzliche Prozessoren die Lage nie verschlechtern; die Beschleunigung flacht nur ab. Reale verteilte Systeme werden oft tatsächlich schlechter: Ab einem gewissen Punkt senken weitere Knoten den Durchsatz. Neil Gunthers Universal Scalability Law (USL) modelliert das mit zwei Abzügen. Konkurrenz (α, Alpha) sind die Kosten des Wartens auf geteilte Ressourcen, derselbe Effekt wie Amdahls serieller Anteil. Kohärenz (β, Beta) sind die Kosten, Daten zwischen Knoten konsistent zu halten: Jeder Knoten muss mit jedem anderen Informationen austauschen, sodass diese Kosten ungefähr mit dem Quadrat der Knotenzahl wachsen.

Die relative Kapazität ist C(N) = N ÷ (1 + α(N − 1) + βN(N − 1)). Mit β = 0 reduziert sie sich auf Amdahls Gesetz. Mit jedem β über null erreicht die Kapazität bei etwa N = √((1 − α) ÷ β) einen Höchstwert und fällt dann. Für α = 0,03 und β = 0,002 liegt der Höchstwert bei etwa √(0,97 ÷ 0,002) ≈ 22 Knoten, mit einer Kapazität von etwa dem 8,6-Fachen eines Knotens; bei 32 Knoten ist die Kapazität wieder auf etwa 8,2 gesunken. Gunther beschreibt das Modell in Guerrilla Capacity Planning (2007). Sein praktischer Wert liegt darin, dass sich α und β an eine Handvoll Lasttest-Messungen anpassen lassen, sodass Sie vorhersagen können, wo sich Skalierung nicht mehr lohnt, bevor Sie die Hardware kaufen.

Taktiken für Performance: ein Überblick

Bass, Clements und Kazman ordnen Performance-Taktiken in zwei Familien. Die erste ist, den Ressourcenbedarf zu steuern: zu verringern, wie viel Arbeit ankommt oder wie viel jede Einheit kostet. Die zweite ist, Ressourcen zu verwalten: die verfügbaren Ressourcen stärker zu nutzen oder mehr davon hinzuzufügen. Die meisten realen Entwürfe kombinieren mehrere Taktiken; jede hat auch anderswo Kosten, weshalb es sich um Architekturentscheidungen handelt.