...

./nxrg-qa/src/test/resources/dk/nsp/nxrg/test/verification/RegistrerDokumentsaetMedReferenceIdList.feature

Performance test

Følgende beskrivelser er "work in progress" og justeres til, som tingene bliver lagt fast og gjort færdigt.

Der laves performance test for hver af de 4 snitflader:

• Iti 18: registry stored query (“find documents”)
• Iti 42: register document  (create)
• Iti 61: register on demand document (replace)
• Iti 57: update document (status deprecate)

For at antallet af performance test ikke bliver alt for stort, køres der test på iti-42 create (create er et nyt dokument, som registreres) og på iti-61 replace (replace er det at erstattet et dokument med et andet). Tanken bag denne beslutning er følgende:

• der skal testes både iti-42 og iti-61, selvom de minder meget om hinanden
• forskellen på create og replace er ikke stor, men begge typer bør testes
• ved at teste de to request på denne “kryds-måde" med create/replace vil eventuelle performance problemer blive synliggjort uden at der skal køres 4 testkørsler.

Performance krav

Der laves performance test af regsistry og repository som et hele - dvs det er brugeroplevelsen som sådan, der vurderes.

Test suiten, der køres, består af følgende kald. De bør udføres i angivne orden. Og databasen til registry og repository kan med fordel kopieres efter trin 2, sådan at de følgende test kan genkøres, skulle behovet opstå.

1. ITI-41: register stable document
2. ITI-61: register on-demand document
   (tag kopi af databaserne)
3. ITI-41: replace stable document
4. ITI-61: replace on-demand document
5. ITI-18: registry stored query (“find documents”) og ITI-43: retrieve document set
6. ITI-57: update metadata (deprecate document)

Der køres på en liste af cpr numre. Trin 1 og 2 opretter data og trin 3-6 arbejder herefter på disse data. Replace document og update metadata arbejder på konkrete dokumenter. Disse findes ved først at lave en ITI-18 søgning, som udelades af selve throughput beregningen.

Performance krav

Der findes i projektet selv, ikke en liste af krav til performance. Fremsøgning (iti-18) er det kald, som vil blive udført oftest og som sådan vil belaste XDS registry mest. Det vil derfor være hensigtsmæssigt at undersøge, hvordan performance er for dette kald er i den det nuværende XDS registry . Derudover skal den gennerelle performance for NXRG synliggøres(og repository). Men vil herefter kunne vurdere, at man ialtfald ikke er dårligere stillet med det nye.

Krav:

1. Iti-18 snitfladen Snitfladerne skal være mindst lige så hurtig som for den nuværende XDS registry De øvrige 3 snitflader (iti-42, 61 og 57repository)
2. Snitfladerne skal måles og svartiderne vurderes
3. Måling Vurdering af, hvor stort et load, de fire snitflader snitfladerne kan håndtere per time og per uge 

Add 23: Der måles en periode på 15 minutter og denne ganges op på time og uge basis.

Forudsætninger

Testen skal køres på en liste af cpr numre. Listen indeholder 100.000 forskellige cpr numre. Udover disse cpr numre skal testen være selvstændig og ikke være afhængig af andet test data.

Testen skal køre mod et registry og repository med en “passende” mængde baggrundsdata. Dette er :

1. Antal dokumenter
2. Fordelt på antal CPR numre:
3. Dokumenttyper:
4. Antal fordelt på dokumenttyper:
5. Fordelt på antal status:

(Antal afgøres når eksisterende XDS registry er undersøgt.)

Baggrundsdata

Baggrundsdata for test kørslerne oprettes med SQL inserts. De anvendte CPR numre og relevant dokument information gemmes i tekstfiler, som performance testen kan køre på.

Udover fordelingen angivet ovenfor i "forudsætninger" gemmes dokumenterne fordelt over en 3 årig periode.

For at test kørslerne kan arbejde på data som findes i databasen, anvender de tekst filer, som input. Derfor er der brug for følgende tekst filer:

• En liste over alle cpr numre, som har dokumenter (iti-18 og iti-42)
• For den dokumenttype, der køres iti-61 test mod, med status “approved”: liste over cpr numre med tilhørende entryUuid (iti-61)
• For dokumenter med “approved” status: liste over cpr numre med tilhørende entryUuid, typecode og repositoryUniqueId (iti-57)

SQL scripts og teksfiler kan med fordel generes fra et java program. Sådan at med en given fordeling af de forskellige parametre som cpr og dokumenttyper skabes sql inserts og tilhørende tekstfiler der hænger sammen.

et par millioner dokumenter af typerne stable og on-demand. Disse skabes i testens trin 1 og 2.

Baggrundsdata

Testens trin 3-6 forudsætter er der findes baggrundsdata at køre på. Trin 3 og 4 skal erstattet eksisterende dokumenter, og trin 5 skal fremsøge eksisterende dokumenter, og trin 6 skal deprecate eksisterende dokumenter.

Dette baggrundsdata skables i testens trin 1 og 2. Vurderes det, at disse 2 trin ikke har skabt nok baggrundsdata (et par millioner dokumenter) kan trin 1 og 2 gentages indtil, der er nok dokumenterVedr baggrundsdata til iti-18 test mod eksisterende XDS registry. Da vi ikke kender databasens opbygning for det eksisterende XDS registry, skabes baggrundsdata med en “test” i jmeter på iti-42 kaldet. Der sættes en række iti-42 kald op i et loop (konfigureret med data som ovenstående nævnt) og antal “loops” sættes for testen, som herefter køres.

Design af test

iti-18 registry stored query

...