Performance-Regressionen frühzeitig erkennen und vermeiden

Um die wilde JVM zu bändigen, müssen wir Messungen mit wissenschaftlicher Genauigkeit ausführen und wiederholen. Wichtig ist dabei vor allem, dass die Messausführung so gestaltet wird, dass die Ergebnisse reproduzierbar sind – zweimal dasselbe Experiment sollte also zum selben Ergebnis führen.

Die Messergebnisse unterscheiden sich innerhalb einer VM aufgrund der beschriebenen nichtdeterministischen Effekte und zwischen VMs, u. a. aufgrund der unterschiedlichen Optimierungen, die die JVM ausführt. Um Messergebnisse innerhalb einer VM (weitestgehend) reproduzierbar zu machen, müssen wir die Messung des Workloads innerhalb einer VM wiederholen, bis ein sog. stationärer Zustand eingetreten ist. Die Workload-Ausführungen bis zum stationären Zustand werden Warmup-Iterationen genannt. Der stationäre Zustand ist dadurch gekennzeichnet, dass keine übermäßigen Schwankungen zwischen den Workload-Wiederholungen mehr auftreten. Eine anerkannte Definition sowie statistische Kriterien für den stationären Zustand stehen noch aus. Für konkrete Anwendungsfälle ist es hilfreich, den Verlauf der Ausführungsdauern optisch zu inspizieren.

Ist das Warmup abgeschlossen, so bleibt in der Regel eine gewisse Schwankung, u. a. durch Garbage Collections, bestehen. Um trotz der Schwankungen repräsentative Messwerte zu erhalten, werden nach dem Warmup mehrere Mess-Iterationen ausgeführt. Deren Mittelwert wird anschließend genutzt.

Die Messergebnisse unterscheiden sich zwischen VMs, da die unterschiedlichen nichtdeterministischen Effekte zu verschiedenen stationären Zuständen führen. Es ist daher nicht ausreichend, nur eine JVM-Ausführung zu nutzen. Stattdessen muss der gesamte Messprozess inklusive Warmup- und Mess-Iterationen eine bestimmte Anzahl von VM-Starts (auch: Forks) wiederholt werden, bis eine gute Grundlage für den Vergleich von Messungen gegeben ist.

Ein weiteres Problem der Messung (v. a. kleiner Workloads) ist, dass der Aufruf der Zeitfunktion selbst Zeit benötigt und Ungenauigkeit erzeugt. Um die Genauigkeit zu erhöhen, wird der Workload daher oft innerhalb einer Iteration mehrfach ausgeführt, so dass in einer Mess-Iteration die aggregierte Ausführungszeit mehrerer Workload-Ausführungen erfasst wird. Abb. 2 fasst diesen Prozess zusammen.

Das Implementieren von Benchmarks in JMH ist der goldene Weg, um Performance-Regressionen zu erkennen. Es hat in der täglichen Softwareentwicklung aber drei Nachteile:

1. Die Testausführung ist ressourcenaufwändig,
2. die Testdefinition erfordert viel Entwickleraufwand und
3. die Ursache von Performance-Unterschieden ist oft unklar.

Das Jenkins-Plugin Peass (Performance Analysis of Software Systems) bietet eine Lösung für diese Nachteile [3]:

1. Es enthält eine Regressionstest-Selektion, die bestimmt, für welche Tests in der aktuellen Version Messungen ausgeführt werden müssen und reduziert so die benötigten Ressourcen fürs Testen.
2. Darüber hinaus transformiert Peass bestehende JUnit-Tests in Performancetests, und erlaubt es damit, die bestehenden Testdefinitionen zu nutzen.
3. Um die Ursache von Performance-Unterschieden zu bestimmen, enthält Peass eine Ursachenanalyse.

Eine Regressionstest-Selektion hilft uns immer dann, wenn wir eine große Menge von Tests haben und nur die aufrufen wollen, bei denen eine Regression aufgetreten sein kann. Für die Performance-Messung ist das besonders relevant, da die Messung selbst erheblich zeitaufwändiger ist als bspw. die einfache Ausführung eines Unittests. Eine große (JMH-)Testsuite ist somit gar nicht regelmäßig in der CI ausführbar.

Grundannahme der Regressionstest-Selektion ist, dass wir bei bei der Entwicklung von Software in einzelnen Commits oft nur einige Klassen oder sogar nur einzelne Methoden einer Klasse ändern. Es ergibt daher keinen Sinn, immer die Performance aller Benchmarks zu messen: Die Performance eines Benchmarks kann sich nur dann geändert haben, wenn sich der aufgerufene Quelltext ändert. Peass bestimmt daher durch eine instrumentierte Ausführung die (geordnete) Liste aller aufgerufenen Methoden und führt Benchmarks nur dann aus, wenn sich eine aufgerufene Methode oder deren Reihenfolge geändert hat.

Abb. 4 verdeutlicht dies: Ruft Test 1 Methode A1 und Methode 1B auf, und nur Methode 1B wird geändert, dann muss Test 1 gemessen werden. Tests 2-5 müssen aber nicht gemessen werden, solange keine von ihnen aufgerufenen Methoden (oder die Tests selbst) geändert werden.

Problematisch ist nun noch, dass die Definition eigener Benchmarks für wichtige Teile einer Software zu aufwändig ist. Peass bietet deshalb die Möglichkeit, Unittests zu transformieren (oder bestehende JMH-Benchmarks zu nutzen). Hier werden die Unittests automatisiert so umgeschrieben, dass der Workload innerhalb einer VM für die angegebenen Aufwärm- und Mess-Iterationen ausgeführt und eine konstante Anzahl an Wiederholungen innerhalb einer Iteration wiederholt wird. Peass automatisiert sowohl die Transformation als auch den mehrfachen Start der Ausführungs-VMs, so dass man als Entwickler lediglich die Konfiguration vornehmen muss.

Unittests weisen darüber hinaus mit oft vorhandenen Assertions einen Mechanismus auf, der in der Regel dazu führt, dass die JVM Ergebnisse von Workloads nicht wegoptimiert. Man muss also als Entwickler lediglich die Ausführung konfigurieren und auswählen, welche Unittests geeignet sind, die Performance zu messen.

Listing 6: Additionstest

public class AdditionTest {
   @Test
   public void testApp() {
      int sum = AdditionClass.addRandomNumbers(1000);
      Assert.assertNotNull(sum);
   }
}

Listing 6 zeigt einen beispielhaften Unittest für das Zahlen-Addieren-Beispiel. Existieren nun zwei Versionen in einem git-Repository und werden in einer Version 1.000 und in der anderen Version 2.000 Zahlen addiert, dann kann Peass die beiden Versionen messen und die Performance der Unittests vergleichen.

Abb. 5 zeigt das Ergebnis der Messungen: Da die regelmäßigen Assertions andere Charakteristika als System.out und Blackhole haben, sind die konkreten gemessenen Werte wieder leicht unterschiedlich gegenüber den vorherigen Messungen. Die Relation bleibt aber gleich: Eher ist P gleich NP, als dass 1.000 und 2.000 Zahlen sequenziell addieren gleich schnell ist.

Performance-Änderungen und Commits in großen Projekten sind oft komplexer und schwerer zu finden als funktionale Probleme – und selbst in Zeiten schwer verfügbarer neuer Hardware ist der damit einhergehende Personalaufwand oft zu groß. Um die Suche zu beschleunigen, bietet Peass zusätzlich eine Ursachenanalyse an. Hierfür wird die Ausführungszeit jedes Knoten des Aufrufbaums separat gemessen, und ermittelt, wo Performance-Änderungen und Quelltext-Änderungen vorliegen. Da die Messung einzelner Knoten Overhead verursacht, gibt es verschiedene Messmodi: Der Aufrufbaum kann ebenenweise gemessen werden, so dass die Messung einer Ebene nicht die darüber liegenden Ebenen beeinflusst. Dies ist zeitaufwändig. Alternativ kann der gesamte Aufrufbaum gemessen werden, was die Messung beschleunigt, aber aufgrund des Overheads weniger exakt ist. Darüber hinaus besteht die Möglichkeit, die Pfade im Aufrufbaum zu messen, die zu Quelltextänderungen führen – dabei entsteht nur ein geringer Mess-Overhead, die Zeit für die Messung selbst ist aber relativ gering.

Abb. 6 zeigt dies in unserem Beispiel: Beide Methoden weisen eine Verlangsamung auf, aber nur AdditionTest#testApp weist eine Quelltextänderung auf. Dadurch wird es möglich, Ursachen von Performance-Änderungen schnell zu identifizieren.