Gå till slutet av bannern
Gå till början av bannern

EI - Lasttester ny

Hoppa till slutet på meta-data
Gå till början av metadata

Du visar en gammal version av den här sidan. Visa nuvarande version.

Jämför med nuvarande Visa sidhistorik

Version 1 Nästa »

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. Se Teststrategi för SKLTP komponenter, avsnittet lasttester för mer information.

Beskrivning av lasttester

  • LoadTestVP, kombinerar anrop till Ping, GetSubjectOfCare och SendMedicalCertificateAnswer. 
  • LoadTestVPSomeFail, kombinerar anrop till Ping, GetSubjectOfCare och SendMedicalCertificateAnswer samt ca 30 % fel i form av VP004, VP007 och VP009.
  • LoadTestVPAllFail, kombinerar anrop till felsituationer för VP004, VP007 och VP009.

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.

Ping OK

  • Logisk adress: Ping
  • Tjänstekontrakt: urn:riv:itinfra:tp:PingResponder:1
  • URL: Internt till VPs TestPingProducent

Ping VP009

  • Logisk adress: PRODUCER-NOT-AVAILABLE 
  • Tjänstekontrakt: urn:riv:itinfra:tp:PingResponder:1
  • URL: Peka på en annan maskin i samma nät, men ange en "ogiltig" port samt non-existing-service. T.ex. http://xx.yy.zz:9876/non-existing-service. 
    NOTE! 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)

SendMedicalCertificateAnswer OK

  • Logisk adress: Test
  • Tjänstekontrakt: urn:riv:insuranceprocess:healthreporting:SendMedicalCertificateAnswerResponder:1
  • URL: Peka på testproducent för denna tjänst. Denna testproducent finns driftsatt internt NTjP på en Mockserver.

SendMedicalCertificateAnswer VP007

Lägg inte till behörighet för denna logiska adress och anropande konsument!

  • Logisk adress: CONSUMER_NOT_AUTHORIZED
  • Tjänstekontrakt: urn:riv:insuranceprocess:healthreporting:SendMedicalCertificateAnswerResponder:1
  • URL: Peka på testproducent för denna tjänst. Denna testproducent finns driftsatt internt NTjP på en Mockserver.

GetSubjectOfCareSchedule OK

  • Logisk adress: HSA-ID-4
  • Tjänstekontrakt: urn:riv:crm:scheduling:GetSubjectOfCareScheduleResponder:1
  • URL: Peka på testproducent för denna tjänst. Denna testproducent finns driftsatt internt NTjP på en Mockserver.

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.

2. Konfiguration Gatling

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:

  • 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.

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å CPU kurvan.

4. Kör happy days tester, LoadTestVP

  1. 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)
  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

5. Kör mixade happy days och felfall tester, LoadTestVPSomeFail

  1. 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)
  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

6. Kör felfall tester, LoadTestVPAllFail

  1. Kör en testomgång med låg last (noOfUsers=1) och dokumentera utfallet.
  2. Kör testomgångar med antalet användare uppskruvat så att du kommer upp i hälften av lasten för brytpunkten för Happy Days testerna och dokumentera utfallet.


  • Inga etiketter