Erscheinungsbild
Testcenter Lasttest 2026
Einleitung
Titel: Bewertung der Skalierbarkeit und Leistung des Testcenters unter hoher Benutzerlast bei unterschiedlichen Testheftgrößen und gleichzeitigen Zugriffen.
Datum: 12. Februar 2025
Tester: Kompetenztest.de
Der Fokus liegt auf der Analyse der Antwortzeiten, Fehlerraten und Serverauslastung bei verschiedenen Hardware-Konfigurationen (VM1, VM2, VM3) und der Untersuchung der Auswirkungen von 100, 200 und 500 gleichzeitigen Benutzern auf die Systemleistung.
1. Testumgebung
Hardware
Server:
- VM1: 1 Kern mit 2 Threads, 8 GB RAM
- VM2: 2 Kerne mit 4 Threads, 8 GB RAM
- VM3: 8 Kerne mit 16 Threads, 8 GB RAM
Client:
- Lenovo ThinkPad T16 Gen 2, AMD Ryzen 7 PRO 7840U (8 Kerne, 16 Threads), 32 GB RAM
- Symmetrischer Gigabit Netzwerkanschluss im Netzwerk der Friedrich Schiller Universität Jena (fast.com Speedtest: 900 Mbps Download, 930 Mbps Upload, Latenz: 8ms)
Software
- Betriebssystem: Oracle Linux 8
- Datenbank: MySQL 8
- Anwendungsframework: Slim 4
- Frontendframework: Angular 16
Tools
- Node Exporter, Prometheus, Grafana (Monitoring Tool)
2. Teststrategie
Testarten
- Lasttest: Überprüfung der Performance bei 100, 200 und 500 gleichzeitigen Benutzern.
- Spitzentest: Überprüfung der Reaktion des Systems auf plötzliche Lastspitzen und hohe gleichzeitige Benutzerzahlen.
Testmethoden
Nutzung von Go-Skript: Um die gleichzeitigen Benutzeranfragen zu simulieren, wird das GO-Scripts des IQBs verwendet (https://github.com/iqb-berlin/load-test). Dabei wird die Anzahl der gleichzeitigen Benutzer (100, 200, 500) dynamisch gesteuert und die Antwortzeiten sowie die Fehlerhäufigkeit überwacht.
Testheftgrößen: Zwei verschiedene Testheftgrößen werden getestet, um die Systemleistung bei unterschiedlichen Datenmengen zu messen.
Überwachung mit Prometheus und Grafana: Während der Tests wird das Monitoring-Tool Prometheus und Grafana verwendet, um die Serverauslastung (CPU, Arbeitsspeicher, Netzwerk), Antwortzeiten und Fehlerraten in Echtzeit zu überwachen und zu analysieren.
Durchführung bei unterschiedlichen Hardwarekonfigurationen: Die Tests werden auf verschiedenen Hardwarekonfigurationen durchgeführt (VM1, VM2, VM3).
3. Testszenarien
1. Szenario: Aufruf der Startseite
Beschreibung:
Simuliert die Szenarien von der Authentifizierung bis hin zum Laden des Testes und deren Inhalte. Es wird überprüft, wie das System mit verschiedenen Lastbedingungen umgeht und wie die Antwortzeiten sowie die Serverauslastung sind.
Ziele:
- Messen der Antwortzeit bei Authentifizierung und Laden der Testinhalte.
- Überprüfung der Fehlerhäufigkeit (z. B. 404 Fehler).
- Analyse der Serverauslastung (CPU, Speicher, Netzwerk).
Gleichzeitige Benutzer:
- 100, 200, 500 Benutzer
4. Testkonfiguration
Zugriffsanzahl
- Test bei 100 gleichzeitigen Zugriffen
- Test bei 200 gleichzeitigen Zugriffen
- Test bei 500 gleichzeitigen Zugriffen
Hardwarekonfigurationen
- VM1: 1 Kern mit 2 Threads, 8 GB RAM
- VM2: 2 Kerne mit 4 Threads, 8 GB RAM
- VM3: 8 Kerne mit 16 Threads, 8 GB RAM
Testgrößen
- Kleine Testgröße: Pilotierungstestheft Basiskompetenztest Lesen (18 MB)
- Große Testgröße: VERA3 Deutsch Lesen 2024 (30,4 MB)
5. Metriken
- Antwortzeiten: Durchschnitt, 95. Perzentil
- Fehlerraten: HTTP-Fehler, Timeouts
- Serverauslastung: CPU, Arbeitsspeicher, Netzwerk
6. Ergebnisse
6.1 Ergebnisse bei VM1 und kleiner Testheftgröße
Verteilung der Antwortzeiten
| Metrik | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| Gesamtzeit | 36,62 s | 71,42 s | 206,70 s |
| Durchschnittliche Antwortzeit | 35,43 s | 62,64 s | 144,08 s |
| 90. Perzentil | 36.51 s | 70,83 s | 205,43 s |
Fehlerarten
| Fehlerart | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| HTTP 500 | 0 | 0 | 0 |
| Timeout | 0 | 0 | 0 |
Grafana Grafiken
Abbildung 1: Antwortzeiten bei VM1 mit kleiner Testheftgröße und 100 gleichzeitigen Zugriffen
Abbildung 2: Antwortzeiten bei VM1 mit kleiner Testheftgröße und 200 gleichzeitigen Zugriffen
Abbildung 3: Antwortzeiten bei VM1 mit kleiner Testheftgröße und 500 gleichzeitigen Zugriffen
6.2 Ergebnisse bei VM1 und großer Testheftgröße
Verteilung der Antwortzeiten
| Metrik | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| Gesamtzeit | 63,91 s | 127,86 s | 314,31 s |
| Durchschnittliche Antwortzeit | 62,32 s | 115,60 s | 258,18 s |
| 90. Perzentil | 63,83 s | 127,46 s | 310,46 s |
Fehlerarten
| Fehlerart | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| HTTP 500 | 0 | 0 | 0 |
| Timeout | 0 | 0 | 0 |
Grafana Grafiken
Abbildung 1: Antwortzeiten bei VM1 mit großer Testheftgröße und 100 gleichzeitigen Zugriffen
Abbildung 2: Antwortzeiten bei VM1 mit großer Testheftgröße und 200 gleichzeitigen Zugriffen
Abbildung 3: Antwortzeiten bei VM1 mit großer Testheftgröße und 500 gleichzeitigen Zugriffen
6.3 Ergebnisse bei VM2 und kleiner Testheftgröße
Verteilung der Antwortzeiten
| Metrik | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| Gesamtzeit | 22,29 s | 40,69 s | 107,09 s |
| Durchschnittliche Antwortzeit | 19,40 s | 31,28 s | 97,40 s |
| 90. Perzentil | 22,19 s | 40,56 s | 106,39 s |
Fehlerarten
| Fehlerart | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| HTTP 500 | 0 | 0 | 0 |
| Timeout | 0 | 0 | 0 |
Grafana Grafiken
Abbildung 1: Antwortzeiten bei VM2 mit kleiner Testheftgröße und 100 gleichzeitigen Zugriffen
Abbildung 2: Antwortzeiten bei VM2 mit kleiner Testheftgröße und 200 gleichzeitigen Zugriffen
Abbildung 3: Antwortzeiten bei VM2 mit kleiner Testheftgröße und 500 gleichzeitigen Zugriffen
6.4 Ergebnisse bei VM2 und großer Testheftgröße
Verteilung der Antwortzeiten
| Metrik | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| Gesamtzeit | 39,42 s | 77,89 s | 186,50 s |
| Durchschnittliche Antwortzeit | 38,62 s | 74,08 s | 161,51 s |
| 90. Perzentil | 39,27 s | 76,45 s | 184,05 s |
Fehlerarten
| Fehlerart | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| HTTP 500 | 0 | 0 | 0 |
| Timeout | 0 | 0 | 0 |
Grafana Grafiken
Abbildung 1: Antwortzeiten bei VM2 mit großer Testheftgröße und 100 gleichzeitigen Zugriffen
Abbildung 2: Antwortzeiten bei VM2 mit großer Testheftgröße und 200 gleichzeitigen Zugriffen
Abbildung 3: Antwortzeiten bei VM2 mit großer Testheftgröße und 500 gleichzeitigen Zugriffen
6.5 Ergebnisse bei VM3 und kleiner Testheftgröße
Verteilung der Antwortzeiten
| Metrik | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| Gesamtzeit | 18,10 s | 30,63 s | 72,20 s |
| Durchschnittliche Antwortzeit | 15,31 s | 26,50 s | 65,94 s |
| 90. Perzentil | 16,98 s | 29,49 s | 70,89 s |
Fehlerarten
| Fehlerart | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| HTTP 500 | 0 | 0 | 0 |
| Timeout | 0 | 0 | 0 |
Grafana Grafiken
Abbildung 1: Antwortzeiten bei VM3 mit kleiner Testheftgröße und 100 gleichzeitigen Zugriffen
Abbildung 2: Antwortzeiten bei VM3 mit kleiner Testheftgröße und 200 gleichzeitigen Zugriffen
Abbildung 3: Antwortzeiten bei VM3 mit kleiner Testheftgröße und 500 gleichzeitigen Zugriffen
6.6 Ergebnisse bei VM3 und großer Testheftgröße
Verteilung der Antwortzeiten
| Metrik | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| Gesamtzeit | 31,87 s | 52,63 s | 128,46 s |
| Durchschnittliche Antwortzeit | 25,17 s | 48,69 s | 118,82 s |
| 90. Perzentil | 29,04 s | 51,69 s | 127,44 s |
Fehlerarten
| Fehlerart | 100 Benutzer | 200 Benutzer | 500 Benutzer |
|---|---|---|---|
| HTTP 500 | 0 | 0 | 0 |
| Timeout | 0 | 0 | 0 |
Grafana Grafiken
Abbildung 1: Antwortzeiten bei VM3 mit großer Testheftgröße und 100 gleichzeitigen Zugriffen
Abbildung 2: Antwortzeiten bei VM3 mit großer Testheftgröße und 200 gleichzeitigen Zugriffen
Abbildung 3: Antwortzeiten bei VM3 mit großer Testheftgröße und 500 gleichzeitigen Zugriffen
7. Analyse
Infrastruktur & Reverse Proxy
Die Standardkonfiguration unserer Oracle Cloud beinhaltet einen Loadbalancer. Ursprünglich wurde das Testcenter mit dieser Konfiguration getestet, wobei ein zusätzlicher Reverse Proxy vorgeschaltet war. Allerdings traten hierbei Probleme auf.
Da wir unsere Server nicht horizontal skalieren, war der Nutzen des Loadbalancers gering. Der einzige Vorteil bestand in der TLS-Terminierung außerhalb des Testcenters, was minimale Verbesserungen der Antwortzeiten brachte. Aufgrund der erhöhten Komplexität und der aufgetretenen Probleme haben wir uns jedoch entschieden, die Konfiguration erstmal ohne Loadbalancer weiter zu testen.
Beobachtungen aus den Lasttestgrafiken
Hohe CPU-Auslastung bei niedriger Netzwerkauslastung bei kleinen Maschinen:
- Ursache: Login-Prozesse laufen sequentiell ab.
- PHP öffnet für jeden Request einen neuen Thread, was ressourcenintensiv ist.
- Die CPU wird stark belastet, während das Netzwerk erst nach Abschluss der Backend-Verarbeitung genutzt wird.
Zielsetzung für gleichzeitige Requests:
- Unser Ziel war es, dass 200 gleichzeitige Requests zu Retries führen dürfen, aber nicht zu Fehlern.
- Mit einer Maschine mit 8 Kernen und 8 GB RAM erreichten wir ein gutes Ergebnis.
- Wir werden zunächst mit dieser Konfiguration arbeiten und während der Tests die Systemauslastung weiter überwachen, um ggf. die Anzahl der Kerne zu reduzieren.