Empirisch gestützte Optimierung des Saros Session-Starts

Um in Saros eine Session mit mehreren Teilnehmern durchzuführen, wird zu Beginn eine Synchronisierung der Projektdaten (Workspace) durchgeführt. Hierzu wird aktuell vom Host ein Zip mit allen Dateien des Projektes geschnürt, an die restlichen Teilnehmer verschickt und dort entpackt. Der Nachteil besteht darin, dass die Teilnehmer warten müssen bis alle Dateien entpackt sind, also der Austausch abgeschlossen ist. Inzwischen existiert ein zweites Verfahren, welches Ressourcen einzelnd im Hintergrund verschickt und so ermöglicht an bereits übertragenen Dateien zu arbeiten, während die Übertragung der restlichen Dateien noch aktiv ist.

Unklar ist bisher inwieweit sich beide Varianten hinsichtlich der Performance in der Praxis unterscheiden und welche letztendlich verwendet werden sollte. Das Testframework vom Saros-Projekt ermöglicht bisher nur die Feststellung, ob die Implementierung korrekt und funktionsfähig ist. Performancetests sind daher nur in Form von händischen Zeitmessungen möglich und lassen, aufgrund der damit abzudeckenden Testfälle, sehr viel Spielraum für Spekulationen bezüglich der Ursachen und der Praxistauglichkeit, wodurch eine Optimierung und die Wahl der optimalen Strategie sehr erschwert wird.

Erkenntnisinteressen

Da das zugrundeliegende Projekt immer den Ausgangspunkt für den Session-Start darstellt, muss ermittelt werden, ob die enthaltenen Dateien in der Praxis typischen Charakteristiken unterliegen (Größe, Anzahl etc.), bzw. Kategorisierungen möglich sind und ob zwischen diesen und der Performance der Start-Varianten Zusammenhänge existieren. Zusätzlich soll geklärt werden, ob mehrere Start-Varianten überhaupt notwendig sind, also das System schneller und stabiler machen, oder sich in der Praxis letztendlich nur eine auszeichnet.

Meilensteine

1. Erfassung der verfügbaren Start-Varianten und ggf. Fertigstellung (V1 und V2).
2. Implementierung von Messinstrumenten zur Messung der aufgestellten Kenngrößen.
3. Sammeln konkreter Daten durch Testen der Start-Varianten.
4. Analyse und Vergleich der Start-Varianten auf Basis der gewonnenen Daten.

Wöchentlicher Status

Woche 1

• Ist-Zustand erfasst => Hauptproblem: Große Dateien verursachen Heap Space Error
• Einarbeitung in den Saros-Code: Aktivitäten, Ressourcenverteilung, Sessionstart
• Geplant: Fileactivity soll mit großen Dateien umgehen können

Woche 2

• Weiterhin Einarbeitung in den Saros-Code
• STF-Manual gelesen (Saros Test Framework)
• Änderung der Fileactivity (Implementierung)

Woche 3

• Optimierung der Dateiübertragung → Verhinderung eines Heap Space Errors (Marshalling Activities)
• Ergebnis: Dateiaufteilung implementiert

Woche 4

• Testen der optimierten Dateiübertragung + Upload (Gerrit Change 2874)
• Aufstellung von Testfällen (optimale Fileactivity Größe)
• Ergebnis: Funktionalität ist gewährleistet

Woche 5

• Patchoptimierung

Woche 6

• Aufstellung Simulationstestcases (Vergleich der Startvarianten)
• Durchführung der Tests zur Erfassung der optimalen Fileactivity Größe
• Patchoptimierung

Woche 7

• Aufteilung der Fileactivity Klasse in Subklassen
• Beginn der Ausarbeitung

Woche 8

• Implementation eines Feature Toggle für mehrere Start Varianten
• Umstrukturierung der bestehenden V2 als separaten Methodenblock, ohne die V1 zu ersetzen.
• Recherche bzgl. einer Methode zur Abschaltung der Autobuild-Einstellung in Eclipse (Preferences)
• Ausarbeitung

Woche 9

• Integrierung der V2
• Ausarbeitung

Woche 10

• Verbesserung der Aufteilung der Fileactivity Klasse in Subklassen
• Ausarbeitung

Woche 11

• Verknüpfung der durchgeführten Patches und Einrichtung der Testumgebung
• Testdurchführung

Woche 12

• weitere Tests
• Fertigstellung der Ausarbeitung