Performance Test in Racemap

Beim Live-Tracking ist es wie bei allen realtime Anwendungen: Der Dienst soll auch unter extrem hoher Last möglichst stabil und mit möglichst kurzer Latenzzeit laufen. Mit anderen Worten – GPS Verfolgung die den Sportlern 5 min hinterher läuft ist sinnlos 😉

Im Januar hat der Jan von profi.com einen Lasttest für unser Tracking-Portal konzipiert, entwickelt, durchgeführt und ausgewertet. Hier lest ihr, wie es zur Zusammenarbeit mit profi.com kam und was wir von Racemap uns von den automatischen Tests erhofft haben. Zur Vorbereitung des Tests haben wir erstmal mit den Möglichkeiten der TestSuit in unserer Entwicklungsumgebung experimentiert. Um Lizenzkosten zu sparen, arbeiten wir mit JMeter – ein Open Source Tool in Java. Bspw. ist HP LoadRunner ein bekanntes, äquivalentes Produkt für kommerzielle Anwendungen.

Realistisches Testszenario für GPS Verfolgung

Festlegung eines realistischen Test-Szenarios: Zunehmende Teilnehmerzahl (hellgrün - Sportler) und der Zuschauer (lila). Die beiden 6 h Wettkämpfe beginnen, während das 24h-Event schon läuft.

Festlegung eines realistischen Test-Szenarios: Zunehmende Teilnehmerzahl (hellgrün – Sportler) und der Zuschauer (lila). Die beiden 6 h Wettkämpfe beginnen, wenn das 24h-Event schon läuft.

Die Testfälle sollen ein möglichst realistisches Szenario abbilden. Unserer Erfahrung nach verursachen 24h-Events wie Rad am Ring die größte Aufmerksamkeit bei Sportlern und Zuschauern (und damit die größte Last für unser Tracking Portal. Da müssen wir durch, das ist unser Geschäft.). Die finale Version des Tests hat drei parallele Events, bei denen

  • sich eine vorgegebene Anzahl simulierter Sportler über die App zum Live-Tracking anmelden (URL-Aufruf),
  • die Sportler GPS-Daten mit unserer Tracking-App o. einem GPS Sender senden (GPS-Abfrage senden für jeden simulierten Sportler) und
  • eine vorgegebene Anzahl simulierter Zuschauer den Wettkampf im Internet verfolgen.

Event 1 läuft 24 h mit 1000 Sportlern und 2000 Zuschauern. Event 2 & 3 laufen jeweils 6 h mit 250 Sportlern und 500 Zuschauern und beginnen etwas nach dem Start von Event 1. Sportler und Zuschauer werden linear (10 je min) dem Event hinzugefügt. Um sich die Bedeutung der Zahlen besser vorstellen zu können: Im Schnitt schauen Zuschauer etwa 10 min bei einem Live-Stream in Racemap zu. Dieser Erfahrungswert übertragen auf die 2000 kontinuierlichen Zuschauer beim 24 h Event entspricht 288.000 Seitenaufrufe (Hits) der Racemap während der Eventdauer.

Auswertung oder die Nadel im Heuhaufen

Alle Tests wirken über http-Requests auf Racemap und für alle Requests wird die Antwortzeit in ms aufgezeichnet. Damit hat man einen messbaren Parameter für eine zielgerichtete Optimierung. Der Test liefert aus etwa 43 Mio Abfragen über 60 GB an Daten. Man braucht Erfahrung, Gespür und etwas Geduld, um aus der großen Datenmenge verwertbare Informationen zu extrahieren – die Nadel im Heuhaufen zu finden. Damit lassen sich Handlungsstrategien für die Optimierung und Weiterentwicklung ableiten.

Hits pro Sekunde über alle Aktionen - der Wert von ca. 560 Requests bei einem Event steigt auf über 660 Requests pro Sekunde an.

Hits pro Sekunde über alle Aktionen – der Wert von ca. 560 Requests bei einem Event steigt auf über 660 Requests pro Sekunde an, wenn alle drei Events parallel laufen.

Zeit zum Anlegen eines Starters (für Sportler relevant). Solange keine Events laufen unkritisch (sehr gut). Das Anlegen der Starter der beiden zusätzlichen Events reicht jedoch in den Bereich von über 1 Sekunde.

Zeit zum Anlegen eines Starters (für Sportler relevant). Solange keine Events laufen unkritisch (sehr gut). Das Anlegen eines Starters für die beiden zusätzlichen Events reicht jedoch in den Bereich von über 1 Sekunde.

Das Laden der Racemap dauert immer länger, wenn das Event noch mit Startern befüllt wird. An der Stelle sogar ein exponentieller Verlauf erkennbar (uncool). Wenn sich zu einem Event jedoch keine neuen Sportler anmelden, wird schnell ausgeliefert. Das kann höchstens bei großen Events kritisch werden, in die noch ständig Starter einsteigen.

Das Laden der Racemap wird immer langsamer, wenn das Event noch mit Startern befüllt wird. An der Stelle sogar ein exponentieller Verlauf erkennbar (uncool). Wenn sich zu einem Event jedoch keine neuen Sportler anmelden, werden die Informationen wieder schnell ausgeliefert. Das Verhalten kann nur bei sehr großen Events kritisch werden, in die noch ständig Starter einsteigen, wenn das Event schon gestartet ist (zB bei einem Staffelevent).

Ausliefern der GPS Daten - breiter Bereich zw. 300 und 5000 ms. Unser Entwicklungsziel ist klar viel häufiger unter 1000 ms zu bleiben. Kurios: Der Bereich wird breiter, wenn die kleinen Events parallel laufen.

Ausliefern der GPS Daten – breiter Bereich zw. 300 und 5000 ms. Unser Entwicklungsziel ist klar viel häufiger unter 1000 ms zu bleiben. Kurios: Der Bereich wird breiter, wenn die kleinen Events parallel laufen.

Anhand der Testergebnisse konnten wir kurzfristig durch eine kleine Änderung der Datenbankabfrage, bei der wird die frisch eintrudelnden GPS-Daten einem Sportler zugeordnen, eine Beschleuninigung unseres Tracking-Services erzielen. Quick Win!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.