Wir freuen uns, euch heute die erste öffentliche Version von Rally vorzustellen – ein Benchmarking-Tool, das unser Elasticsearch-Entwicklerteam intern bereits seit ein paar Monaten verwendet.

Wir möchten Rally allen zur Verfügung stellen, damit unsere veröffentlichten Performance-Zahlen nachvollziehbar sind, die wir in unserer eigenen Umgebung erzielen. Außerdem könnt ihr damit eure eigenen Benchmarks erstellen, ohne euch um die vielen kleinen Details Gedanken zu machen.

Die Ursprünge von Rally

Rally stammt ursprünglich von Python-Skripts, die die nächtlichen Elasticsearch-Benchmarks und auch die nächtlichen Lucene-Benchmarks ausführen.

Die Benchmarking-Infrastruktur eignet sich hervorragend, um den Boiling-Frog-Effekt zu vermeiden (d. h. dass langsam Leistung eingebüßt wird). Wir optimieren Elasticsearch kontinuierlich in allen Bereichen und auch die Performance ist uns sehr wichtig. Wäre es nicht toll, wenn Entwickler selbst anhand von Benchmarks bereits in einem frühen Stadium sehen könnten, welche Auswirkungen Änderungen an der Entwicklung haben, anstatt zu warten, bis die Funktion vollständig integriert wird?

Entwickler sind in der Regel kreative Köpfe. Ein schnelles, unsauberes Skript für einen konkreten Anwendungsfall lässt sich in der Sprache unserer Wahl immer schreiben und durchführen, bevor es in Vergessenheit gerät. Doch wie oft verifizieren wir diese Zahlen wirklich?

Also habe ich die naheliegendste Lösung ausprobiert: Ich habe die vorhandenen Benchmark-Skripts lokal eingesetzt, aber die Einrichtung umfasste viele manuelle Schritte. Daher beschloss ich, die Installation und Nutzung zu vereinfachen und Rally war geboren.

Was kann Rally?

In den letzten Monaten sind nach und nach weitere Funktionen zu Rally hinzugekommen:

Wir können sogenannte Telemetrie-Geräte für die detaillierte Verhaltensanalyse des Benchmark-Kandidaten anschließen. Der Java Flight Recorder hat uns beispielsweise schon dabei geholfen, verschiedene Probleme zu erkennen. Hier sind ein paar Beispiele, was mit Rally und Java Flight Recorder, einem Telemetrie-Gerät, alles möglich ist:

Allocation-Profiling

Prüfung von Hot Classes in Elasticsearch

Wir haben auch ein Telemetrie-Gerät für den JIT-Compiler hinzugefügt, mit dem wir sein Verhalten prüfen können und das uns dabei hilft, die Warmup-Zeiten während des Benchmark-Zeitraums zu analysieren. Die Grafiken unten zeigen die Anzahl an JIT-Compiler-Events während des Benchmark-Tests:

Die Performance-Evaluation bei solch einem komplexen System wie Elasticsearch ist auch ein multidimensionales Problem. Wenn die Performance in einem Szenario optimiert werden kann, – z. B. bei der Suche nach Log-Daten – wirkt sich das unter Umständen negativ auf die Volltextsuche aus. Aus diesem Grund können wir mehrere Benchmarks definieren (diese werden bei Rally „Tracks“ genannt). Sie sind derzeit direkt in die Code-Basis von Rally implementiert, aber wenn die API stabil genug ist, möchten wir die Tracks separieren, damit ihr selbst eigene Tracks definieren könnt.

Da Rally alle Metrikdaten in Elasticsearch speichert, können wir die Daten mit Kibana ganz leicht visuell darstellen lassen, so zum Beispiel die Verteilung der CPU-Nutzung während des Benchmark-Tests:

Anfangs fügen wir den Benchmark-Datensatz zum Index hinzu. Danach führen wir Such-Benchmarks durch. Ich wette, ihr könnt ganz klar sehen, wann die Indexierung abgeschlossen ist.

Wir haben auch damit begonnen, die nächtlichen Benchmarks parallel laufen zu lassen und die Ergebnisse als Kibana-Dashboard dargestellt.

Roadmap

Es gibt immer noch viel zu tun:

Ein großes Thema ist die Minimierung von Einschränkungen. Wir möchten die Benchmark-Definitionen (die sogenannten „Tracks“) aus Rally selbst separieren und auch mehr Flexibilität bei den Schritten ermöglichen, die Rally während des Benchmark-Tests durchführt. Im Moment unterstützen wir nur ein sehr eingeschränktes Szenario: Zuerst werden alle Dokumente Bulk-indiziert und dann führen wir eine Track-abhängige Anzahl an Anfragen durch. Standardmäßig führen wir den Benchmark-Test anhand der Daten von geonames.org durch, doch weitere Tracks sind verfügbar (rufe einfach esrally list tracks auf).

Das zweite große Thema ist die Verbesserung der Genauigkeit der Messdaten. Uns ist die Genauigkeit sehr wichtig und wir wissen, dass einige Dinge noch verbessert werden müssen. Eines der größten Probleme ist, dass es bei den Latenz-Messungen zu koordinierten Auslassungen kommt. Das bedeutet im Grunde, dass Anfragen, die längere Zeit für die Verarbeitung brauchen, den Benchmark-Driver davon abhalten, in der Zwischenzeit weitere Anfragen zu stellen. Aus diesem Grund verlieren wir Messwerte. Am Ende wird die Verteilung der Latenz im Bericht besser dargestellt als sie in Wirklichkeit ist.

Drittens: Rally ist derzeit auf Single-Machine-Benchmarks beschränkt, aber wir werden irgendwann Multi-Machine-Benchmarks erlauben.

Durchführung des ersten Benchmark-Tests

Schauen wir uns nun an, wie leicht es ist, einen Benchmark-Test auf einem eigenen System durchzuführen.

Nachdem wir alle benötigten Programme installiert und Rallys Kennzahlenspeicher gestartet haben, gelangen wir in drei Schritten zu den ersten Benchmark-Ergebnissen: pip3 install esrally esrally configure esrally --pipeline=from-distribution --distribution-version=5.0.0-alpha1

Wenn ihr mehr über Rally erfahren möchtet, schaut einfach auf Rallys Projektseite vorbei, seht euch ein paar Probleme an oder helft uns, indem ihr selbst Tracks oder Änderungen zu Rally beitragt.

Das Bild am Anfang des Beitrags wurde von Andrew Basterfield unter der CC BY-SA-Lizenz (Originalquelle) bereitgestellt. Die Farben des Bildes wurden angepasst, ansonsten ist das Bild unverändert.