EI - Lasttester

Owned by Mats Ekhammar (Unlicensed)
Last updated: juni 24, 2015
3 min read

Lasttester hittas i katalogen test/non-functional/Gatling i utcheckad källkod.

Testscenario vid prestandamätningar

Vid prestandamätningar vill vi bestämma olika gränsvärden för EI när det gäller uppdaterande meddelanden (Update)

  • Hur många anrop / sekund vi klarar att ta emot innan svarstiden ökar med ca 25 %. Detta gäller för meddelanden som endast innehåller en post.
  • Hur många anrop / sekund vi klarar att ta emot utan att kön som som betar av meddelanden till databasen växer. Detta gäller för meddelanden som innehåller 1000 poster.

En vanlig sökning i EI via FindContent ingår också för att verifiera funktionen under hög last.

Dessutom vill vi köra en mix av meddelanden (olika mängder poster) för att se att EI uppför sig robust över tid. (Robusthetstest?)

Se Teststrategi för SKLTP komponenter, avsnittet lasttester för mer information.

Beskrivning av lasttester

  • LoadTestEI_Update_1, test av Update tjänsten med små meddelanden
  • LoadTestEI_Update_1000, test av Update tjänsten med stora meddelanden 
  • LoadTestEI_FindContent, test av FindContent tjänsten

Konfiguration av lasttesterna

För att kunna köra lasttesterna behöver varje typ av anrop som ingår i lasttesterna konfigureras enligt nedan i Tjänsteadresseringskatalogen (TAK). För alla nedanstående konfigurationer skall det läggas till vägval samt behörighet om det ej står annat. Notera anropande certifikats HSA-Id så att detta kan läggas till i TAK:en för behörighetskonfigurationen.

Update

  • Logisk adress: 5565594230
  • Tjänstekontrakt: urn:riv:itintegration:engagementindex:UpdateResponder:1
  • URL: https://qa.esb.ntjp.se/vp/Update/1/rivtabp21

FindContent

  • Logisk adress: 5565594230
  • Tjänstekontrakt: urn:riv:itintegration:engagementindex:FindContentResponder:1
  • URL: https://qa.esb.ntjp.se/vp/FindContent/1/rivtabp21

Instruktioner för att utföra 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

Starta JConsole och logga på den/de VP-noder du vill se CPU-lasten för.

Logga in på Adminverktyget för att kunna se ködjup för EI köer.

2. Konfiguration Gatling

Gatling tester körs enligt den generella instruktionen - ny. Testet nedan avser  testet LoadTestEI_Update_1 som normalt körs mot NTjP i QA. Kompletterande information till dessa enligt nedan:

  • 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.
    • testTimeSecs - anger hur länge testet skall köras, default är 30 sekunder.
    • startPnr - anger för vilket personnummer vi skall börja generera testdata. Dvs de två första siffrorna i det genererade personnumret.

  • Verifiera att logisk adress i XML-meddelanden (src/test/resources/data/Update_1_OK.xml) som används är satt till 5565594230 
  • Verifiera att om man kör via en VP-instans skall URL till tjänsterna vara enligt följande (src/test/resources/scala/se/skltp/ei/Scenarios.scala)
    • /vp/Update/1/rivtabp21
    • vp/FindContent/1/rivtabp21

3. Dokumentation

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.

Dokumentation skall även ske över CPU-belastningen under testet, detta görs lämpligen genom att ta en skärmdump av jConsole och då på CPU kurvan.

4. Kör LoadTestEI_Update_1

  1. Börja med att köra en testomgång med låg last (noOfUsers=1) och dokumentera utfallet. Kör 60 sek långa tester. (Kör gärna om för att få två oberoende värden).
  2. Räkna ut vilken medelsvarstid som motsvarar en 20-25% ökning.
  3. Kör en ny testomgång med en markant ökning av antalet användare, förslagsvis 40 användare. Verifiera också att CPU-lasten inte går över 60% i snitt under testet. Glöm inte att stega upp startPnr inför varje ny testomgång!
  4. Korrigera antalet användare för att nå en ca 20-25% ökning av svarstiden och dokumentera efter hand, glöm inte bild över CPU-lasten

5. Kör LoadTestEI_Update_1000

  1. Börja med att köra en testomgång med låg last (noOfUsers=1) och dokumentera utfallet. Kör 120 sek långa tester. (Kör gärna om för att få två oberoende värden).
  2. Verifiera att köerna (skltp.ei.process) inte byggs på
  3. Öka antalet användare (noOfUsers) lite försiktigt och se att det inte byggs på meddelanden på kön.Verifiera också att CPU-lasten inte går över 60% i snitt under testet samt glöm inte att stega upp startPnr inför varje ny testomgång!
  4. Korrigera antalet användare för att se när köerna börjar byggas på.

6. Kör LoadTestEI_FindContent

  1. Kör en testomgång med låg last (noOfUsers=1) och dokumentera utfallet.
  2. Räkna ut vilken medelsvarstid som motsvarar en 20-25% ökning.
  3. Kör en ny testomgång med en markant ökning av antalet användare, förslagsvis 40 användare. Verifiera också att CPU-lasten inte går över 60% i snitt under testet.
  4. Korrigera antalet användare för att nå en ca 20-25% ökning av svarstiden och dokumentera efter hand, glöm inte bild över CPU-lasten.