For ikke at antallet af performance test 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

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 for dette kald er i den nuværende XDS registry. Derudover skal den gennerelle performance for NXRG synliggøres.

Krav:

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

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

Forudsætninger

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

Antal dokumenter
Fordelt på antal CPR numre:
Dokumenttyper:
Antal fordelt på dokumenttyper:
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.

Vedr 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

Dette er en fremsøgning af dokumenter.

Overvejelser omkring opsætningen

søg på færre dokumenttyper, end der findes
søg på indsnævret dato interval i forhold til fuld liste

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

CPR tilfældigt fra liste af numre
Både stable og on-demand dokumenter
Dato interval: det midterste år ud af de 3 tilgængelige
Dokument typer, som hentes

PHMR (53576-5)
APD (56446-8)
QRD (74465-6)
FSK (52460-3)

Der søges efter “approved” dokumenter (deprecate udelades)

iti-42

Dette er en registrering af et “stable” dokument.

Overvejelser omkring opsætningen

Opret nye dokumenter
Anvend forskellige cpr numre

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

CPR tilfældigt fra liste af numre
Der anvendes derudover de i ovenstående skærmbillede angivne test data eller tilsvarende (faktisk anvendte angives i performance rapporten)

iti-61

Dette er en registrering af et “on-demand” dokument, som erstatning fra et allerede eksisterende.

Overvejelser omkring opsætningen

Opret et erstatnings dokument
Anvend forskellige cpr numre og dokumenter

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

CPR tilfældigt fra liste af numre
Dokumentet som opdateres er fra samme liste som CPR numret
Der anvendes derudover de i ovenstående skærmbillede angivne test data eller tilsvarende (faktisk anvendte angives i performance rapporten)

iti-57

Dette er en opdatering af til et eksisterende dokuments metadata.

Overvejelser omkring opsætningen

Anvend forskellige cpr numre og dokumenter

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

CPR tilfældigt fra liste af numre
Dokumentet som opdateres er fra samme liste som CPR numret
Der deprecates

Nye opgaver i forbindelse med ovenstående

I forbindelse med ovenstående design af test, er følgende punkter dukket frem, som ting, der skal kigges på/ laves:

Er det muligt at lave en performance test af nuværende XDS registry som beskrivet ovenfor?
- Hvis ja, så skal iti-42 kaldende sættes op i en test med en liste af cpr numre
Produktionsdata skal undersøges som beskrevet i “forudsætninger”
Der skal laves et program (i NXRG QA modulet), som kan skabe SQL/ tekstfiler baggrundsdata (der findes allerede logik, som kan genbruges)
Der er følgende nye justeringer til det nuværende test framework, på baggrund af ovenstående:
- Test at iti-18, iti42 kan køre på liste af cpr numre
- iti-61 (og iti-42) rettes sådan at replace funktionalitet køre på liste af cprnumre og entry ids (Forslag: getCitizenCPRNumber skal læse 2 parametre og gemme entryuuid i threadcontext)
- iti-57 rettes sådan at deprecate funktionalitet køre på liste af cprnumre og entry ids mm (Forslag: getCitizenCPRNumber skal læse flere parametre og gemme dokumentEntry specifikke i threadcontext)

Udførsel af test

Forberedelse

Testen hentes fra https://svn.nspop.dk/svn/components/performance/trunk i den revision, der er angivet nedenfor per release af NXRG.

Databasen klargøres. Tom database, de respektive scripts, som nævnt under baggrundsdata, køres.

Der skal være en kørende version af NXRG, man kan teste imod. Og host.properties skal være sat korrekt op jf. arosiis performance test framework.