Lasttester hittas i katalogen ….loadTest i utcheckad källkod.
Testscenario vid prestandamätningar
Vid prestandamätningar vill vi hitta hur många anrop / sekund virtualiseringsplattformen klarar att släppa igenom innan svarstiderna ökar.
- Som referens, mät svarstider vid låg belastning och dokumentera i testprotokollet
- Öka antal request / s tills man märker av ökad belastning i form av ökade svarstider (ca +20%) och / eller ökad CPU (ca 60%) och dokumentera i testprotokollet.
Beskrivning av lasttester
- PingHttp, gör anrop mot intern Ping-tjänst via http.
- PingHttps, gör anrop mot intern Ping-tjänst via https.
- GetSubjectOfCareHttps, gör anrop mot tjänsten GetSubjectOfCare (förväntas routas till testproducent för denna tjänst).
- SendMedicalCertificateAnswer, gör anrop mot tjänsten SendMedicalCertificateAnswer (förväntas routas till testproducent för denna tjänst).
- LoadTestVP, kombinerar anrop till Ping, GetSubjectOfCare och SendMedicalCertificateAnswer.
Instruktioner för att utföra de automatiserade happy days testerna
Syftet med detta test är att mäta prestanda vid korrekta anrop. Vi vill även kunna säkerställa att prestanda inte försämras mellan två releaser.
1. Förberedelser
Innan testet utförs måste det definieras vilken konfigurationen av VP som är intressant för mätningarna. Följande inställningar påverkar prestandan:
- Payloadloggning på eller av.
- Loggning till ActiveMQ på eller av.
Starta också JConsole och logga på den/de VP-noder du vill se CPU-lasten för.
2. Konfiguration
Gatling tester körs enligt den generella instruktionen - ny. Testet nedan avser testet LoadTestVP som normalt körs av NTjP i QA. Kompletterande information till dessa enligt nedan:
- Lasttestet som skall köras heter LoadTestVP.
- Parametrar till testet enligt listan nedan. Anges genom flaggan -D<parameter>=<värde> vid start av testerna.
- noOfUsers - anger hur många simulerade användare vi skall använda, default är 10
- baseUrl - anger URL för vp-tjänsterna, default är https://localhost:20000
Testerna förutsätter att miljön som skall testas är konfigurerad korrekt, dvs routing och behörighet till testproducenter är korrekta.
Testerna baseras på ett antal testproducenter.
- Testproducent deployad i VP för Ping
- Testproducent deployad på MockServern för tjänsten GetSubjectOfCareSchedule
- Testproducent deployad på MockServern för tjänsten SendMedicalCertificateAnswer
Dokumentation av lasttestet sker i ett testprotokoll (mall testprotokoll). Spara också utfallet för varje test från Gatling genom att zippa hela katalogen där resultatet ligger och bifoga testprotokollet.
3. Kör tester
- Börja med att köra en testomgång med låg last (noOfUsers=1) och dokumentera utfallet. (Kör gärna om för att få två oberoende värden)
- Räkna ut vilken medelsvarstid som motsvarar en 20-25% ökning.
- Kör en ny testomgång med en markant ökning av antalet användare, förslagsvis 40 användare. Dokumentera utfallet samt verifiera att CPU-lasten inte gått över 50-60% (ta en bild!).
- Korrigera antalet användare för att nå en ca 20-25% ökning av svarstiden och dokumentera efter hand.
Test 2 - Prestandamätning vid felfall
Syfte med testet
Syftet med detta test är att mäta prestanda vid de vanligaste felfallen. Vi vill även kunna säkerställa att prestanda inte försämras mellan två releaser.
Följande felfall ska observeras:
- Konfigurationsfel
Routingfel
TAK setup (routing entry till en annan maskin i samma subnät som VP-instansen, men med en port som inte används, vi ska använda riktiga HTTP-anrop (utan genvägar i lokal-nätverksstack, men till en host vi "äger" så att network-latency inte skiljer mellan mätningar (som det skulle kunna göra med en extern host) :Logisk adress: PRODUCER-NOT-AVAILABLE Adress: http://192.168.16.211:9090/non-existing-service Beskrivning: En fejkad adress till ett känt nät