Extending Peass to Detect Performance Changes of Apache Tomcat

New application versions may contain source code changes that decrease the application’s performance. To ensure sufficient performance, it is necessary to identify these code changes. Peass is a performance analysis tool using performance measurements of unit tests to achieve that goal for Java applications. However, it can only be utilized for Java applications that are built using the tools Apache Maven or Gradle. This thesis provides a plugin for Peass that enables it to analyze applications built with Apache Ant. Peass utilizes the frameworks Kieker and KoPeMe to record the execution traces and measure the response times of unit tests. This results in the following tasks for the Peass-Ant plugin: (1) Add Kieker and KoPeMe as dependencies and (2) Execute transformed unit tests. For the first task, our plugin programmatically resolves the transitive dependencies of Kieker and KoPeMe and modifies the XML buildfiles of the application under test. For the second task, the plugin orchestrates the process that surrounds test execution—implementing performance optimizations for the analysis of applications with large codebases—and executes specific Ant commands that prepare and start test execution. To make our plugin work, we additionally improved Peass and Kieker. Therefore, we implemented three enhancements and identified twelve bugs. We evaluated the Peass-Ant plugin by conducting a case study on 200 commits of the open-source project Apache Tomcat. We detected 14 commits with 57 unit tests that contain performance changes. Our subsequent root cause analysis identified nine source code changes that we assigned to three clusters of source code changes known to cause performance changes.:1. Introduction 1.1. Motivation 1.2. Objectives 1.3. Organization 2. Foundations 2.1. Performance Measurement in Java 2.2. Peass 2.3. Apache Ant 2.4. Apache Tomcat 3. Architecture of the Plugin 3.1. Requirements 3.2. Component Structure 3.3. Integrated Class Structure of Peass and the Plugin 3.4. Build Modification Tasks for Tomcat 4. Implementation 4.1. Changes in Peass 4.2. Changes in Kieker and Kieker-Source-Instrumentation 4.3. Buildfile Modification of the Plugin 4.4. Test Execution of the Plugin 5. Evaluative Case Study 5.1. Setup of the Case Study 5.2. Results of the Case Study 5.3. Performance Optimizations for Ant Applications 6. Related Work 6.1. Performance Analysis Tools 6.2. Test Selection and Test Prioritization Tools 6.3. Empirical Studies on Performance Bugs and Regressions 7. Conclusion and Future Work 7.1. Conclusion 7.2. Future WorkNeue Versionen einer Applikation können Quelltextänderungen enthalten, die die Performance der Applikation verschlechtern. Um eine ausreichende Performance sicherzustellen, ist es notwendig, diese Quelltextänderungen zu identifizieren. Peass ist ein Performance-Analyse-Tool, das die Performance von Unit-Tests misst, um dieses Ziel für Java-Applikationen zu erreichen. Allerdings kann es nur für Java-Applikationen verwendet werden, die eines der Build-Tools Apache Maven oder Gradle nutzen. In dieser Arbeit wird ein Plugin für Peass entwickelt, das es ermöglicht, mit Peass Applikationen zu analysieren, die das Build-Tool Apache Ant nutzen. Peass verwendet die Frameworks Kieker und KoPeMe, um Ausführungs-Traces von Unit-Tests aufzuzeichnen und Antwortzeiten von Unit-Tests zu messen. Daraus resultieren folgende Aufgaben für das Peass-Ant-Plugin: (1) Kieker und KoPeMe als Abhängigkeiten hinzufügen und (2) Transformierte Unit-Tests ausführen. Für die erste Aufgabe löst das Plugin programmbasiert die transitiven Abhängigkeiten von Kieker und KoPeMe auf und modifiziert die XML-Build-Dateien der zu testenden Applikation. Für die zweite Aufgabe steuert das Plugin den Prozess, der die Testausführung umgibt, und führt spezielle Ant-Kommandos aus, die die Testausführung vorbereiten und starten. Dabei implementiert es Performanceoptimierungen, um auch Applikationen mit einer großen Codebasis analysieren zu können. Um die Lauffähigkeit des Plugins sicherzustellen, wurden zusätzlich Verbesserungen an Peass und Kieker vorgenommen. Dabei wurden drei Erweiterungen implementiert und zwölf Bugs identifiziert. Um das Peass-Ant-Plugin zu bewerten, wurde eine Fallstudie mit 200 Commits des Open-Source-Projekts Apache Tomcat durchgeführt. Dabei wurden 14 Commits mit 57 Unit-Tests erkannt, die Performanceänderungen enthalten. Unsere anschließende Ursachenanalyse identifizierte neun verursachende Quelltextänderungen. Diese wurden drei Clustern von Quelltextänderungen zugeordnet, von denen bekannt ist, dass sie eine Veränderung der Performance verursachen.:1. Introduction 1.1. Motivation 1.2. Objectives 1.3. Organization 2. Foundations 2.1. Performance Measurement in Java 2.2. Peass 2.3. Apache Ant 2.4. Apache Tomcat 3. Architecture of the Plugin 3.1. Requirements 3.2. Component Structure 3.3. Integrated Class Structure of Peass and the Plugin 3.4. Build Modification Tasks for Tomcat 4. Implementation 4.1. Changes in Peass 4.2. Changes in Kieker and Kieker-Source-Instrumentation 4.3. Buildfile Modification of the Plugin 4.4. Test Execution of the Plugin 5. Evaluative Case Study 5.1. Setup of the Case Study 5.2. Results of the Case Study 5.3. Performance Optimizations for Ant Applications 6. Related Work 6.1. Performance Analysis Tools 6.2. Test Selection and Test Prioritization Tools 6.3. Empirical Studies on Performance Bugs and Regressions 7. Conclusion and Future Work 7.1. Conclusion 7.2. Future Wor

Untersuchung von Performanzveränderungen auf Quelltextebene

Änderungen am Quelltext einer Software können zu veränderter Performanz führen. Um das Auftreten von Regressionen zu verhindern und die Effekte von Quelltextänderungen, von denen eine Verbesserung erwartet wird, zu überprüfen, ist die Messung der Auswirkungen von Quelltextänderungen auf die Performanz sowie das tiefgehende Verständnis des Laufzeitverhaltens der beteiligten Quelltextkonstrukte notwendig. Die Spezifikation von Benchmarks oder Lasttests, um Regressionen zu erkennen, erfordert immensen manuellen Aufwand. Für das Verständnis der Änderungen sind anschließend oft weitere Experimente notwendig. In der vorliegenden Arbeit wird der Ansatz Performanzanalyse von Softwaresystemen (Peass) entwickelt. Peass beruht auf der Annahme, dass Performanzänderungen durch Messung der Performanz von Unittests erkennbar ist. Peass besteht aus (1) einer Methode zur Regressionstestselektion, d. h. zur Bestimmung, zwischen welchen Commits sich die Performanz geändert haben kann basierend auf statischer Quelltextanalyse und Analyse des Laufzeitverhaltens, (2) einer Methode zur Umwandlung von Unittests in Performanztests und zur statistisch zuverlässigen und reproduzierbaren Messung der Performanz und (3) einer Methode zur Unterstützung des Verstehens von Ursachen von Performanzänderungen. Der Peass-Ansatzes ermöglicht es somit, durch den Workload von Unittests messbare Performanzänderungen automatisiert zu untersuchen. Die Validität des Ansatzes wird geprüft, indem gezeigt wird, dass (1) typische Performanzprobleme in künstlichen Testfällen und (2) reale, durch Entwickler markierte Performanzänderungen durch Peass gefunden werden können. Durch eine Fallstudie in einem laufenden Softwareentwicklungsprojekt wird darüber hinaus gezeigt, dass Peass in der Lage ist, relevante Performanzänderungen zu erkennen.:1 Einleitung 1.1 Motivation 1.2 Ansatz 1.3 Forschungsfragen 1.4 Beiträge 1.5 Aufbau der Arbeit 2 Grundlagen 2.1 Software Performance Engineering 2.2 Modellbasierter Ansatz 2.2.1 Überblick 2.2.2 Performanzantipattern 2.3 Messbasierter Ansatz 2.3.1 Messprozess 2.3.2 Messwertanalyse 2.4 Messung in künstlichen Umgebungen 2.4.1 Benchmarking 2.4.2 Lasttests 2.4.3 Performanztests 2.5 Messung in realen Umgebungen: Monitoring 2.5.1 Überblick 2.5.2 Umsetzung 2.5.3 Werkzeuge 3 Regressionstestselektion 3.1 Ansatz 3.1.1 Grundidee 3.1.2 Voraussetzungen 3.1.3 Zweistufiger Prozess 3.2 Statische Testselektion 3.2.1 Selektierte Änderungen 3.2.2 Prozess 3.2.3 Implementierung 3.3 Tracevergleich 3.3.1 Selektierte Änderungen 3.3.2 Prozess 3.3.3 Implementierung 3.3.4 Kombination mit statischer Analyse 3.4 Evaluation 3.4.1 Implementierung 3.4.2 Exaktheit 3.4.3 Korrektheit 3.4.4 Diskussion der Validität 3.5 Verwandte Arbeiten 3.5.1 Funktionale Regressionstestbestimmung 3.5.2 Regressionstestbestimmung für Performanztests 4 Messprozess 4.1 Vergleich von Mess- und Analysemethoden 4.1.1 Vorgehen 4.1.2 Fehlerbetrachtung 4.1.3 Workloadgröße der künstlichen Unittestpaare 4.2 Messmethode 4.2.1 Aufbau einer Iteration 4.2.2 Beenden von Messungen 4.2.3 Garbage Collection je Iteration 4.2.4 Umgang mit Standardausgabe 4.2.5 Zusammenfassung der Messmethode 4.3 Analysemethode 4.3.1 Auswahl des statistischen Tests 4.3.2 Ausreißerentfernung 4.3.3 Parallelisierung 4.4 Evaluierung 4.4.1 Vergleich mit JMH 4.4.2 Reproduzierbarkeit der Ergebnisse 4.4.3 Fazit 4.5 Verwandte Arbeiten 4.5.1 Beenden von Messungen 4.5.2 Änderungserkennung 4.5.3 Anomalieerkennung 5 Ursachenanalyse 5.1 Reduktion des Overheads der Messung einzelner Methoden 5.1.1 Generierung von Beispielprojekten 5.1.2 Messung von Methodenausführungsdauern 5.1.3 Optionen zur Overheadreduktion 5.1.4 Messergebnisse 5.1.5 Überprüfung mit MooBench 5.2 Messkonfiguration der Ursachenanalyse 5.2.1 Grundlagen 5.2.2 Fehlerbetrachtung 5.2.3 Ansatz 5.2.4 Messergebnisse 5.3 Verwandte Arbeiten 5.3.1 Monitoringoverhead 5.3.2 Ursachenanalyse für Performanzänderungen 5.3.3 Ursachenanalyse für Performanzprobleme 6 Evaluation 6.1 Validierung durch künstliche Performanzprobleme 6.1.1 Reproduktion durch Benchmarks 6.1.2 Umwandlung der Benchmarks 6.1.3 Überprüfen von Problemen mit Peass 6.2 Evaluation durch reale Performanzprobleme 6.2.1 Untersuchung dokumentierter Performanzänderungen offenen Projekten 6.2.2 Untersuchung der Performanzänderungen in GeoMap 7 Zusammenfassung und Ausblick 7.1 Zusammenfassung 7.2 AusblickChanges to the source code of a software may result in varied performance. In order to prevent the occurance of regressions and check the effect of source changes, which are expected to result in performance improvements, both the measurement of the impact of source code changes and a deep understanding of the runtime behaviour of the used source code elements are necessary. The specification of benchmarks and load tests, which are able to detect performance regressions, requires immense manual effort. To understand the changes, often additional experiments are necessary. This thesis develops the Peass approach (Performance analysis of software systems). Peass is based on the assumption, that performance changes can be identified by unit tests. Therefore, Peass consists of (1) a method for regression test selection, which determines between which commits the performance may have changed based on static code analysis and analysis of the runtime behavior, (2) a method for transforming unit tests into performance tests and for statistically reliable and reproducible measurement of the performance and (3) a method for aiding the diagnosis of root causes of performance changes. The Peass approach thereby allows to automatically examine performance changes that are measurable by the workload of unit tests. The validity of the approach is evaluated by showing that (1) typical performance problems in artificial test cases and (2) real, developer-tagged performance changes can be found by Peass. Furthermore, a case study in an ongoing software development project shows that Peass is able to detect relevant performance changes.:1 Einleitung 1.1 Motivation 1.2 Ansatz 1.3 Forschungsfragen 1.4 Beiträge 1.5 Aufbau der Arbeit 2 Grundlagen 2.1 Software Performance Engineering 2.2 Modellbasierter Ansatz 2.2.1 Überblick 2.2.2 Performanzantipattern 2.3 Messbasierter Ansatz 2.3.1 Messprozess 2.3.2 Messwertanalyse 2.4 Messung in künstlichen Umgebungen 2.4.1 Benchmarking 2.4.2 Lasttests 2.4.3 Performanztests 2.5 Messung in realen Umgebungen: Monitoring 2.5.1 Überblick 2.5.2 Umsetzung 2.5.3 Werkzeuge 3 Regressionstestselektion 3.1 Ansatz 3.1.1 Grundidee 3.1.2 Voraussetzungen 3.1.3 Zweistufiger Prozess 3.2 Statische Testselektion 3.2.1 Selektierte Änderungen 3.2.2 Prozess 3.2.3 Implementierung 3.3 Tracevergleich 3.3.1 Selektierte Änderungen 3.3.2 Prozess 3.3.3 Implementierung 3.3.4 Kombination mit statischer Analyse 3.4 Evaluation 3.4.1 Implementierung 3.4.2 Exaktheit 3.4.3 Korrektheit 3.4.4 Diskussion der Validität 3.5 Verwandte Arbeiten 3.5.1 Funktionale Regressionstestbestimmung 3.5.2 Regressionstestbestimmung für Performanztests 4 Messprozess 4.1 Vergleich von Mess- und Analysemethoden 4.1.1 Vorgehen 4.1.2 Fehlerbetrachtung 4.1.3 Workloadgröße der künstlichen Unittestpaare 4.2 Messmethode 4.2.1 Aufbau einer Iteration 4.2.2 Beenden von Messungen 4.2.3 Garbage Collection je Iteration 4.2.4 Umgang mit Standardausgabe 4.2.5 Zusammenfassung der Messmethode 4.3 Analysemethode 4.3.1 Auswahl des statistischen Tests 4.3.2 Ausreißerentfernung 4.3.3 Parallelisierung 4.4 Evaluierung 4.4.1 Vergleich mit JMH 4.4.2 Reproduzierbarkeit der Ergebnisse 4.4.3 Fazit 4.5 Verwandte Arbeiten 4.5.1 Beenden von Messungen 4.5.2 Änderungserkennung 4.5.3 Anomalieerkennung 5 Ursachenanalyse 5.1 Reduktion des Overheads der Messung einzelner Methoden 5.1.1 Generierung von Beispielprojekten 5.1.2 Messung von Methodenausführungsdauern 5.1.3 Optionen zur Overheadreduktion 5.1.4 Messergebnisse 5.1.5 Überprüfung mit MooBench 5.2 Messkonfiguration der Ursachenanalyse 5.2.1 Grundlagen 5.2.2 Fehlerbetrachtung 5.2.3 Ansatz 5.2.4 Messergebnisse 5.3 Verwandte Arbeiten 5.3.1 Monitoringoverhead 5.3.2 Ursachenanalyse für Performanzänderungen 5.3.3 Ursachenanalyse für Performanzprobleme 6 Evaluation 6.1 Validierung durch künstliche Performanzprobleme 6.1.1 Reproduktion durch Benchmarks 6.1.2 Umwandlung der Benchmarks 6.1.3 Überprüfen von Problemen mit Peass 6.2 Evaluation durch reale Performanzprobleme 6.2.1 Untersuchung dokumentierter Performanzänderungen offenen Projekten 6.2.2 Untersuchung der Performanzänderungen in GeoMap 7 Zusammenfassung und Ausblick 7.1 Zusammenfassung 7.2 Ausblic