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

Version 1 Nästa »

VP - Lasttester

Introduktion

Lasttester hittas i folden ….Testscript / Load Test

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 tjänsteplatformen klarar att släppa igenom innan svarstiderna ökar. 

  1. Som referens, mät svarstider vid låg belastning.
  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%). 
  3. Dokumentera antal req/s, svarstid (medel + 95 kvantil) samt CPU.

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. Default (2.2.6) är med payloadloggning, styrs via konfig enligt SKLTP VP - Konfiguration#Konfiguration-VP2.2.2ochsenare.
    Not: här måste vi ha lite större payload än vad VP's Ping-tjänst ger, borde vara en dedicerad tjänst för test men vi använder just nu Kalendercentralen (https://www.kalendercentralen.se/Schedulr/).
    Uppsatt att ge ca 2.3kb stort respons (requesten är < 1kb). 
  2. Prestanda utan Payloadloggning med loggning till Active MQ
  3. Prestanda med Payloadloggning utan loggning till Active MQ
  4. Prestanda utan Payloadloggning utan loggning till Active MQ

Köra Gatling tester

Kör Gatling tester enligt den generella instruktionen. Kompletterande information till punkt 1:

  1. Ladda ner distributionen från Gatling Project, testscript verifierade på gatling-charts-highcharts-1.5.3-bundle.zip

  2. Checka ut VP's gatling script och kopiera innehållet i request-bodies och simulations till din gatling installation

    svn checkout http://skltp.googlecode.com/svn/tp/vp/trunk/testScripts/
 

  3. Testerna baseras på ett antal testproducenter. (TBD, uppdatera instruktioner var dessa teststubbar finns tillgängliga)


    1. Kalendercentralen demotidbok

    2. Testproducent deployad i VP för tidbokning 
    3. Testproducent deployad i VP för Ping
    4. Testproducent deployad i FKAdaptern för tjänsten sendMedicalCertificateAnswer

  4. Finns inte alla tillgängliga kan man uppdatera gatling scriptet genom att plocka bort den som saknas.

    //setUp(scnAdam.users(adam_noOfUsers).ramp(rampUpTimeSecs).protocolConfig(httpConf))
//setUp(scnErik.users(erik_noOfUsers).ramp(rampUpTimeSecs).protocolConfig(httpConf))
//setUp(scnKc.users(erik_noOfUsers).ramp(rampUpTimeSecs).protocolConfig(httpConf))
setUp(scnPing.users(ping_noOfUsers).ramp(rampUpTimeSecs).protocolConfig(httpConf))
//setUp(scnSendMedicalCertificateAnswer.users(sendMedicalCertificateAnswer_noOfUsers).ramp(rampUpTimeSecs).protocolConfig(httpConf))

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