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

SKLTP VP - 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

« Föregående Version 6 Nästa »

VP - Lasttester

Introduktion

Lasttester hittas i katalogen ….loadTest

Lasttester utförs i QA miljön. Följande lasttester har definierats


Testscenario vid prestandamätningar

Vid prestandamätningar vill vi hitta hur många anrop / sekund virtualiseringsplattformen klarar att släppa igenom innan svarstiderna ökar. 

  1. Som referens, mät svarstider vid låg belastning och dokumentera i testprotokollet
  2. Ö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.

Test 1 - Prestanda vid Happy days scenario

Syfte med testet

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.

Testinstruktion

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:

  1. Payloadloggning på eller av.
  2. Loggning till ActiveMQ på eller av.

Köra Gatling tester

Kör Gatling tester enligt den generella instruktionen - ny. Kompletterande information till dessa enligt nedan:

  1. Lasttestet som skall köras heter LoadTestVP.
  2. Parametrar till VP tester 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

  3. Testerna förutsätter att miljön under test är konfigurerad för de tester som körs, dvs routing och behörighet till testproducenter är korrekta.

  4. Testerna baseras på ett antal testproducenter.

    1. Testproducent deployad i VP för Ping
    2. Testproducent deployad på MockServern för tjänsten GetSubjectOfCareSchedule
    3. Testproducent deployad på MockServern för tjänsten SendMedicalCertificateAnswer

  5. Om inte alla finns tillgängliga kan man uppdatera gatling scriptet genom att plocka bort den som saknas.

    Scenarios.scn_SendMedicalCertificateAnswerHttps.inject(rampUsers(Conf.noOfUsers.toInt) over (Scenarios.rampUpTimeSecs seconds)).protocols(Conf.httpConf),
Scenarios.scn_GetSubjectOfCareScheduleHttps_2.inject(rampUsers(Conf.noOfUsers.toInt) over (Scenarios.rampUpTimeSecs seconds)).protocols(Conf.httpConf),
Scenarios.scn_PingOkSimulationHttps.inject(rampUsers(Conf.noOfUsers.toInt) over (Scenarios.rampUpTimeSecs seconds)).protocols(Conf.httpConf),
Scenarios.scn_GetSubjectOfCareScheduleHttps.inject(rampUsers(Conf.noOfUsers.toInt) over (Scenarios.rampUpTimeSecs seconds)).protocols(Conf.httpConf),

  6. Dokumentera ufallet av lasttestern 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.

 

NTjP

sjdhfkjsdhfsdfkl

 

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:

  1. Konfigurationsfel

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

      



  • Inga etiketter