Last und Performancetests (Part 2) [M]
Warum?
Um die Last, Performance und Skalierung der Zustelldienstinfrastruktur gewährleisten und einschätzen zu können ist es notwendig, dass wir gegen eine existierende (minimale) Referenzinfrastruktur automatisiert Tests fahren.
Ziele
- Ermitteln von Performanceanforderungen
- Abschätzung von Lastspitzen
- Erkennen von Bottlenecks
Referenzen
- Die zu testenden Größen (z.B. Größe und Anzahl der Attachments) orientiert sich an: https://wiki.fit-connect.fitko.dev/de/Konzeption/Observability_Monitoring
Akzeptanzkriterien
-
Timebox: Für die Durchführung dieses Issue werden maximal 3 Tage Arbeitszeit beansprucht (ohne Wartezeit auf Server). -
Es gibt einen Test, der sehr viel (aber sehr kleine) Anträge verschickt. -
Die erreichte Bandbreite der Tests wird in Form wird dokumentiert. -
Die Ergebnisse sind in Form eines Logs im Wiki dokumentiert. -
Erste Erkenntnisse (falls vorhanden) sind dokumentiert. -
Die Zusammenfassung der Ergebnisse (Anzahl Anfragen/Zeit, max. Größen, etc.) ist als Managment-Summary dokumentiert und wird mit den dokumentierten Metriken verglichen (2-3 Sätze sollten ausreichen). -
Die Last- und Perfomancetests müssen (semi-)automatisiert gegen das Gesamtsystem durchgeführt werden können. Es existiert eine entspreche Doku zur Durchführung der Tests. -
Die Health-Metriken des Hosts (CPU, Memory, etc.) werden protokolliert. -
Die getestete Hardwarekonfiguration ist im Betriebshandbuch oder im Wiki dokumentiert. -
Der Test wurde auf dev
ausgeführt. -
Der Test wurde auf refz
ausgeführt.
Durchführung
-
Server für die Durchführung von Tests beschaffen -
Script erstellen und/der Gatling nutzen -> Ergebnisse aus #349 (closed) können als Vorlage dienen -
Script testen (mit weniger Daten, gegen lokalen Server) -
Durchführung der Tests auf der Dev-Infrastruktur über gemieteten Server, von dem aus Anfragen gestellt werden -
Beteiligte informieren, wann der Test durchgeführt wird -
Durchführung der Tests auf der Staging-Infrastruktur (refz)
Edited by Pascal Osterwinter