Page History
| Navitabs | ||||||
|---|---|---|---|---|---|---|
| ||||||
Indhold
| Table of Contents |
|---|
Introduktion
Dette dokument beskriver udvikling og afvikling af jmeter tests.
Dokumenthistorik
Version | Dato | Ansvarlig | Beskrivelse |
1.0 | 15-11-2018 | Openminds | Oprettelse |
| 1.1 | 14-11-2019 | Lakeside | Opdatering vedr. test krav |
| 1.2 | 25-09-2020 | KvalitetsIT | Opdatering ifm. flytning af test til arosiis performance test framework |
| 1.3 |
| KvalitetsIT |
lookup on behalf of udfases |
Performance
Det følgende beskriver performance test og analyse for
- MinLog2 - Performancetest borger lookup
- MinLog 2 - Performancetest registration
Først i dette afsnit beskrives de forskellige typer test data output, og hvordan de anvendes i analysen. Herefter skitseres scope og afvikling af testene samt performance kravene.
Se iøvrigt krav til performance test og rapport på siden https://www.nspop.dk/display/public/web/Performancekrav
Performance analyse
For alle test gælder følgende:
Udover de fremsatte performance krav på svartid, er der en række andre punkter, som bør analyseres for at vurdere servicens sundhed.
Følgende punkter undersøges derfor:
- Svartid per kald
- Antal kald per sekund
- Cpu status
- io på netværk
- Hukommelses forbrug
- Garbage collection
- Kafka Consumer Lag
Disse undersøgelser foretages vha. de forskellige log filer, som genereres under performance testen. De følgende afsnit gennemgår de vigtigste tal fra disse filer:
- JMeter log data belyser
- Faktisk antal test iteration kørt
- Throughput
- (Ex: docker01.bo.stage.nsp.netic.dk-perflogs/minlog_listlogstatements_borger_stress01.nsp-test.netic.dk_master_20200309_110341.tar.gz.log)
- Access log (applikations server information) belyser
- Antal kald per sekund
- Svartid
- For rapporten vedr. forespørgsler gælder
- De nedenstående grafer som er dannet fra denne log er lavet i splunk af Arosii.
- (Denne log er ikke inkluderet da den indeholder personfølsomme data)
- vmstat log (system information) belyser
- cpu status
- skrivning til disk
- Logning sker hver 10. sekund
- (Ex: docker01.bo.stage.nsp.netic.dk/docker01.bo.stage.nsp.netic.dk-vmstat-20200309101455.log)
- jstat log (JVM information) belyser
- Hukommelse (heap) forbrug
- Garbage collection
- Der er tidsstempel per log linie
- (Ex: docker01.bo.stage.nsp.netic.dk/docker01.bo.stage.nsp.netic.dk-docker-jstat-gc-stage_bo_comp_minlog_backend_lookup.log)
- docker stats log (container information) belyser
- Hukommelse
- io på netværk
- Der er ikke noget fast logningsinterval
- (Ex: docker01.bo.stage.nsp.netic.dk/docker01.bo.stage.nsp.netic.dk-docker-jstat-gc-stage_bo_comp_minlog_backend_lookup.log)
- Kafka Consumer lag
- Relevant ved registrering af data
- Offsets og lag fordelt per topic og partition
- Der er tidsstempel per log linie
- (Ex kafka01.stage.nsp.netic.dk-kafka-consumer-group/minlog-kafka-backend.log)
Hver kørsel/iteration (øgning af belastning) har en start og slut tid. Filerne access.log og jstat.log indeholder tidstempler. Dette muliggør at de kan mappes til en given iteration. Filen vmstat har ikke tidstempel. Men da den starter samtidig med jstat loggen og logintervallet er kendt på 10 sekunder, kan iterationernes placering i data beregnes. Docker stats loggen har hverken tidsstempel eller fast logninginterval, hvorfor tallene/graferne kun kan bruges som en generel betragtning over hele test perioden.
Scope og afvikling
Scope
Testene involverer følgende komponenter
- MinLog 2 service
- NSP kafka
- Galera MariaDB cluster
- NSP standard performance test framework
Versionen af MinLog2 og test frameworket varierer for hver test og fremgår nedenfor.
MinLog 2's overordnede arkitektur ses af følgende figur (kilde: arkitektur dokumentet)
Lookup/forespørgsler test vedrører kun "lookup" komponenten, da der ingen opdateringer (registration ) foregår imens, og der dermed heller ingen aktivitet er på "consumer" komponenten. Dette betyder konkret, at de tilsendte log filer, som vedrører "consumer" komponenten ikke analyseres for lookup rapporterne.
Registration består af 2 komponenter: registration komponenten, som modtager input og gemmer data ned i sin "lokale" kafka. Data herfra flyttes af mirrorMaker over på den centrale kafka i backoffice. Og den anden komponent kafka-consumer, der tager fra den centrale kafka og flytter data i databasen.
Der er ikke målinger på database serveren (MariaDB).
Performance test kald
- MinLog2 - Performancetest borger lookup
- MinLog 2 - Performancetest registration
- Kan kaldes med konfigurerbart antal registreringer per request.
- (Der er oprettet distributioner med forskellige antal registringer per request. Disse er beskrevet under "Udførsel af test".)
- De sidste 5 % af registreringerne i et kald er dupletter. (F.eks.: for 20 registreringer per kald vil den sidste registrering være en duplet af den foregående).
- Kan kaldes med konfigurerbart antal registreringer per request.
Afvikling
Performance testen afvikles på følgende måde
- Testen køres på et test system opsat af Netic
- Testen laves i standard NSP performance frameworket, udviklet af Arosii i JMeter.
- Opdater CSV file path i jmeter sådan passer med systemet
- Der køres en testplan med stadig øget belastning ved at øge antallet af tråde og noder indtil det målte throughput ikke længere vokser med tilsvarende mængde.
- Testplanerne kører typisk 15 minutter per iteration og for læsning hentes 30 entries per side.
- System under test køres på 2 docker containere for lookup, og 4 containere for registration (docker01 og docker02 henholdsvis docker01, docker02, docker03 og docker04 i nedenstående)
Krav
Servicemålene herunder er for henholdsvis MinLog 2 registreringsservices (svartider opdatering) og MinLog2 opslagsservices (Svartider forespørgsler).
| Service | Servicemål |
|---|---|
| Svartider opdatering | 95 % af tilfældene ≤ 6,5 sek |
| 98 % af tilfældene ≤ 15,5 sek | |
Svartider forespørgsler | 95 % af tilfældene ≤ 2,5 sek |
| 98 % af tilfældene ≤ 5,5 sek |
MinLog2 bør testes, da alle snitflader vil blive belastet i indkøringsfasen.
Lookup
Borger
Der skal udarbejdes et CPR nummer SELECT repræsenterende forskellige grupper i forhold til mængder af MinLog2 logninger i alt svarende til 2 % af alle med MinLog2 borger entrys.
| Interval af antal entrys | Antal CPR numre |
|---|---|
| 0 - 50 | 20.000 |
| 50 - 100 | 20.000 |
| 100 - 500 | 20.000 |
| 500 - 1000 | 20.000 |
| 1000 - 5000 | 19.000 |
| 5000 -10.000 (hvis de findes?) | 1.000 |
Sundhedsfaglig - Medhjælpslog
Der skal udarbejdes et CPR nummer SELECT af nedre og øvre kvartil i mængden af MinLog2 logninger svarende til 2 % af alle med MinLog2 medhjælps entrys. CPR nummerne skal være sundhedsfaglige med delegering.
Registration
Der skal udarbejdes et registration sæt som indsættes med 20.000 registringer pr. 5 min interval stigende op mod 60.000 pr. 5 min. interval.
Der skal testes både bulk og single registreringer samt dupletter.
- For bulk registreringer forslåes test af 10, 50, 100, 250 og 500 registreringer per kald.
- I hvert kald er de 5 % sidste registreringer dupletter.
Baggrundsdata
Database
Databasen har indeholdt en kopi af produktion.
Look up Id
Til lookup MinLog2 samt lookup Id ws anvendes følgende fil:
- borger.txt - tekstfil indeholdende borger Id'er.
Registration
Til registration anvendes følgende fil:
- opret.csv - CSV-fil indeholdende 142.895 cpr-numre.
Udførsel af test
Forberedelse
Testen hentes fra https://git.nspop.dk/projects/NT/repos/performance-framework i den revision, der er angivet nedenfor per release af MinLog 2 servicen.
Databasen klargøres.
Der skal være en kørende version af MinLog 2 servicen, man kan teste imod. Og host.properties skal være sat korrekt op jf. arosiis performance test framework.
Kørsel
Når databasen er på plads, servicen kørende og testen configureret kan følgende køres:
Lookupid
run_test.sh -h hosts.properties -p 9012 minlog2 lookupidws test900_10
Registration
run_test.sh -h hosts.properties -p 9012 minlog2 registration test900_10
- Distributionen kan ændres for flere registreringer per request (test900_10, test900_50, test900_100, test900_250, test900_500)
Mulige Distributionen at vælge til test
| Minlog2 distributions |
|---|
| test10_10 |
| test10_50 |
| test10_10 |
| test10_250 |
| test10_500 |
| test300_500 |
| test300_1000 |
| test300_2500 |
| test900_10 |
test900_50 |
test900_100 |
test900_250 |
test900_500 |
Version
MinLog2 Release | Performance test revision |
|---|---|
| 2.*.* | 2.0.* |
| GIT | GIT |
'* ' betyder hvilken som helst
...
Performancetest1
Indhold2
Indledning3
Krav3
Opsætning3
Afviklede tests3
Resultat4
Forventet belastning4
Høj belastning5
Max belastning6
Konklusion7
...
Dette dokument beskriver resultaterne af de afviklede performancetests
...
Erstatnings-cpr-løsningen har følgende krav til svartider (krav 19):
...
- Gennemsnit mindre end eller lig 1000 ms
- 95% under 1250 ms
- 99% under 2000 ms
...
Testen afvikles mod en lokalt installeret NIAB med samme komponenter som produktionsserveren (2013-10-11 - NIAB m. jboss7 uden komponenter pit20130808_01).
Svartidsmålingerne er foretaget ved klienten.
Der kan være forskel på hardware på det miljø, hvori testen er afviklet og det miljø, hvori løsningen skal deployes. Endvidere er der i disse tests minimal netværkstid, da klient og installation kører på samme maskine.
Det betyder, at disse tests kan give en god indikation af de forventede svartider samt opførsel under høj belastning. Men i praksis kan de observerede data i produktionsmiljøet afvige noget fra resultaterne af disse tests.
...
Det forventes, at den mest kaldte metode er GenerateReplacementCPR, hvorfor performancetesten kalder denne.
Testen er afviklet med 50.000 erstatnings-cpr-numre indsat på forhånd.
Testen er kør med følgende belastninger:
- Forventet belastning: 10 transaktioner/minut i en time. Denne test er samtidig en endurancetest, der viser, hvordan svartiderne udvikler sig under en længerevarende belastning.
- Høj belastning: 60 transaktioner/minut med sammenfaldende kald i 10 minutter
- Max belastning. Der er udført tests for at afdække ved hvilken belastning, løsningen går fra at overholde svartidskravene til ikke længere at gøre det.
...
Alle tider er opgivet i ms.
...
10 transaktioner/minut i en time. Kaldene er jævnt fordelt.
Det primære mål med denne test er dels at sandsynliggøre, at kravene til svartider kan overholdes, dels at sandsynliggøre, at svartiderne ikke udvikler sig negativt over tid.
...
Gennemsnit
...
99 percentil
...
95 percentil
...
max
...
min
...
Fejl (%)
...
Målt
...
95
...
233
...
116
...
295
...
73
...
0
...
Krav
...
1.000
...
2.000
...
1.250
...
N/A
...
N/A
...
0
...
60 transaktioner/minut med sammenfaldende kald i 10 minutter.
Denne belasting er 6 gange den forventede.
Formålet med denne test er at undersøge, hvordan svartiderne udvikler sig, hvis belastning øges til et niveau, der er markant højere end det forventede.
...
Gennemsnit
...
99 percentil
...
95 percentil
...
max
...
min
...
Fejl (%)
...
98
...
138
...
126
...
218
...
72
...
0
...
Svartiderne her ligner meget svartiderne ved den forventede belastning, selv om der er en belastning, der er 6 gange større.
...
I forsøg på at afdække ved hvilken belastning, løsningen ikke længere kan leve op til kravene, er der udført to tests med belastninger tæt på hinanden, men hvor der er markant forskel på svartiderne.
- 1200 transaktioner/minut i ca. 5 minutter
b. 1500 transaktioner/minut i ca. 5 minutter
...
Gennemsnit
...
99 percentil
...
95 percentil
...
max
...
min
...
Fejl (%)
...
a.
...
238
...
1.084
...
589
...
2.881
...
87
...
0
...
b.
...
1.147
...
2.385
...
1.942
...
3.847
...
84
...
0
...
Figur 4 Svartidsfordeling a. En markant top omkring 200 m
Figur 5 Svartidsudvikling b. Kaldene fordeler sig omkring 1.000 ms.
Det er markant at svartids billedet er forskudt med omkring 800 ms trods det, at belastningen kun er øget 25 % fra a. til b. Det tyder på, at applikationen bliver presset ved omkring 20-25 kald/sekund.
...
Ved den forventede belastning ligger svartiderne meget langt under de opstillede krav. Ved en belastning, der er 10 gange så stor som den forventede, er svartiden stort set uændret. I begge tilfælde ligger svartiderne nede omkring en tiendedel af kravet.
Afsøgning af den maksimale belastning viser, at løsningen kan overholde svartiden, når belastningen er under ca. 1.200 kald i minuttet – eller ca. 120 gange det forventede. Om det præcist er, hvad løsningen kan håndtere i produktion er det useriøst at udtale sig om. Dog er det sandsynligt, at løsningen kan håndtere markant mere det forventede.
Desuden er det værd at notere sig, at der stadig ikke er kald, der fejler selv om de øgede svartider indikerer, at serveren er lidt presset.
Sammenfattende indikerer performancetesten, at der ikke kan forventes problemer med at leve op til svartiderne.