Ruby verliert gegen Python beim Performance Test – zum Leid des Lead-Entwicklers

Tja – so sieht es wohl aus…

Hintergründe

Der Plan war einfach. Man nehme die Programmiersprache No. 1 der eigenen Wahl und entwickle ein komplettes System in nur einer einzigen Programmiersprache.

So wurde unsere BigData Analytics Lösung ETeeL im Jahr 2020 in der Programmiersprache Ruby gestartet.

Alles klappte – fast zeitgetreu und ohne große Hindernisse.

Die Einzel-Tests mit jeweils kleineren Dateien (1000, 5000 und 100000 Datensätzen zu je 21 Spalten) liefen in 12 Sekunden bis 23 Sekunden komplett von Anfang bis Ende einwandfrei. Das Ergebnis war das erwartete.

Auch bei den Integrations-Tests der einzelnen Komponenten und deren Interkations-Testungen mit den Dateien aus den Einzel-Tests waren komplett erfolgreich.

In beiden Test-Arten wurden dabei jeweils ca. 25 Fehlerfall-Testfälle erzeugt um die gängigsten Missstände und deren Behandlung nachzuweisen.

Die Einzel-Tests der Komponenten und auch die Integrations-Tests liefen also einwandfrei „durch“ – das Konglomerat aus der Plattform selbst, Micro-Services und AWS-Diensten in einer SOA-Landschaft schien geglückt zu sein.

Doch, dann kam der Performance-Test…

Was haben wir dabei getestet ?

Da ein Performance-Test i.d.R. aus mehreren Teilen besteht, hier nur der Vollständigkeit halber eine Auflistung der Bestandteile:

• Load-Testing
• Stress-Testing
• Spike-Testing
• Endurance-Testing
• Scalability-Testing
• Volumen-Testing

Alle Testing-Modus wurden durchgeführt (mehr dazu siehe Themen Testing und Perfomancetest)

Der Performance-Test im Bereich Volume-Test war aufgesetzt wie immer und überall.

Man nehme 3 Verschiedene Dateien mit Lieferdatensätzen (im Format *.csv), eine mit 11 Mio. Datensätzen und 37 Datenspalten (5 GB), eine Datei mit 50 Mio Datensätzen und 96 Datenspalten (43 GB) und eine Datei mit 280 Mio.Datensätzen und 281 Datenspalten (0.9 TB).

Erste Läufe auf der gut ausgestatteten Test-Umgebung liefen mit den Ergebniszeiten

• 11 Mio. Datensätze (5 GB) – Verarbeitung in 72 Sekunden
• 50 Mio. Datensätze (43 GB) – Verarbeitung in 476 Sekunden
• 280 Mio. Datensätze (947 GB) – Verarbeitung in 880 Sekunden (mit Fractioning bzw. Aufsplittung der Datei in mehrere Teile zur parallelen Verarbeitung)
• 280 Mio. Datensätze (947 GB) – Verarbeitung in über 900 Sekunden (ohne Fractioning bzw. Aufsplittung der Datei in mehrere Teile)

durch.

Die 900 Sekunden – oder 15 Minuten – stellen im AWS-Dienst Lambda-Function die maximale Ausführungszeit dar. Nach Ablauf der 900 Sekunden bricht AWS die Ausführung hart ab – ohne Wenn und Aber (Stand Sept. 2022).

Das mag ob der schieren Größe der Test-Dateien „doch ganz gut aussehen“ – möchte man meinen.

Gegentest

Nun ja – mit der Einschränkung, dass hier nur die Beladung getestet wurde und damit die eigentliche Verarbeitung der Daten in Analyse- und Reporting-Schritten noch komplett fehlt, kann man erkennen dass das nicht das Ende der Fahnenstange sein kann und darf.

So hat der Lead-Entwickler entschieden, alle Implementierungen – insbesondere die Performance-Treiber innerhalb der AWS-Dienste – nochmals in der Programmiersprache Python zu realisieren. Der Anfrage und dem Aufwand von 7 Tagen wurde stattgegeben.

Mit den nun neu erzeugten Programm-Elementen auf Basis Python und den selben Test-Dateien (siehe oben) wurden dann folgende Ergebnisse erzielt:

• 11 Mio. Datensätze (5 GB) – Verarbeitung in 57 Sekunden
• 50 Mio. Datensätze (43 GB) – Verarbeitung in 363 Sekunden
• 280 Mio. Datensätze (947 GB) – Verarbeitung in 639 Sekunden (mit Fractioning bzw. Aufsplittung der Datei in mehrere Teile zur parallelen Verarbeitung)
• 280 Mio. Datensätze (947 GB) – Verarbeitung in 889 Sekunden (ohne Fractioning bzw. Aufsplittung der Datei in mehrere Teile)

Bereits die „kleine Datei“ mit rund 11 Mio. Datensätzen und nur 37 Spalten (im Format *.csv) wurde in der Python-Version 15 Sekunden schneller verarbeitet als in der Ruby-Version. Und das obwohl der Code exakt gleich aufgebaut ist und auch exakt das Gleiche tut.

Immer wieder Warum ?

Nach dieser „Schlappe“ der favorisierten Programmiertechnik ging es also für den Lead-Entwickler auf Spurensuche – nach dem Warum.

Nach weiteren 14 Tagen und etlichen Testläufen gab es dann Gewissheit…

Python ist einfach schneller als Ruby – und das wird sich erstmal auch nicht ändern.

Lead-Entwickler

Fazit

Ergebnis wird also ein hybrides Modell aus Ruby, Ruby-on-Rails und Python werden.

Wir werden nach obigen Performance-Erfahrungen zwar die Gesamt-Architektur nicht ändern (müssen) – aber auf einige Teile in der favorisierten Programmiertechnik verzichten

Lead-Entwickler

Da der Gegentest allerdings „mal schnell zwischenrein“ gemacht wurde, stehen die abschließenden Integrations-Tests aller Komponenten noch aus, die Dokumentation muss komplett angepasst werden und die Folge-Tests dann auch noch erfolgreich abschließen.

Erst dann kann die Software dem Kunden „übergeben“ bzw. zugemutet werden.

Wir Erwarten den Abschluss und die Freigabe bis Ende 2022.

Der Ursprünglich avisierte Markteintritt bzw. -start wird von Q4/2022 auf Q1/2023 verschoben (siehe Markteinritt von ETeeL verschoben).