Last und Performancetests (Part 1) [M]
Ziele:
- Was ist die maximale Größe von Anträgen, die wir übermitteln können?
- NEU: Wie hoch ist die Latenz vom Start des Versenden eines Antrags bei Sender bis zum Abschluss des Antragsempfangs beim Subscriber?
- Annahme: Subscriber nutzt Callback
- Bitte auch Dauer von Teilstrecken messen (Dauer Upload Fachdaten, Dauer Upload Anlagen, Dauer Upload insg., Dauer bis zum Auslösen des Callback, Dauer Download, ...)
Klären
-
Wie viel Traffic dürfen wir bei Hetzner verursachen? -> ITOPS-258 => keine Beschränkungen -
Heiko informieren, Rahmenbedingungen abklären -
Wie werden wir die Testdaten wieder los? Kann die DB resettet werden? - Haben wir genug Storage, um die Daten rumliegen zu lassen, bis sie automatisch gelöscht werden. GGf. Löschfristen temporär verringern.
- wir testen nur auf refz, nicht auf prod
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 1-2 Tag Arbeitszeit beansprucht (ohne Wartezeit auf Server). -
Es gibt einen Test, der die maximal unterstützte Größe eines Antrags/Anhangs/Fachdaten bestimmt. -
Vor der Durchführung der Tests auf refz
ist sichergestellt, dass dierefz
-Infrastruktur keinen Einfluss auf den Betrieb desprod
-Servers hat. -
Die erreichte Bandbreite der Tests wird in Form wird dokumentiert. -
Die Ergebnisse sind in Form eines Logs im Wiki dokumentiert. -
Die getestete Hardwarekonfiguration ist im Betriebshandbuch oder im Wiki dokumentiert. -
Die Zusammenfassung der Ergebnisse (Anzahl Anträge/Zeit, max. Größen, etc.) ist als Managment-Summary dokumentiert (2-3 Sätze sollten ausreichen). -
Der Test wurde auf testing
ausgeführt. -
Der Test wurde auf refz
ausgeführt.
Durchführung
-
Server für die Durchführung von Tests beschaffen -
Script erstellen -> https://github.com/codedust/fitconnect-sdk-python/blob/main/sender.py kann als Vorlage dienen -
Script testen (mit weniger Daten, gegen lokalen Server) -
Beteiligte informieren, wann der Test durchgeführt wird (DEV: Entwicklungsteam via Matrix-Chat, TESTING via annouce-mailingliste, REFZ auch via annouce-mailingliste) -
Durchführung der Tests auf der Dev-Infrastruktur über gemieteten Server, von dem aus Anfragen gestellt werden -
Durchführung der Tests auf der Testinfrastruktur über gemieteten Server, von dem aus Anfragen gestellt werden -
Durchführung der Tests auf der Staging-Infrastruktur (refz)
Edited by Marco Holz