Dette dokument dækker udførslen af SKRS performance testen. Se også Performance rapport - Generelt for generelle aspekter omkring testen. 

SKRS

SKRS, Stamdata Kopi Register Servicen, bruges til at replikere stamdata fra NSP til lokale installationer bla. i regionerne. 

SKRS er del af SDM leverancen. Til testen er SDM version 3.5.8 blevet brugt. 

Antagelser og forbehold

Følgende antagelser og forbehold gør sig gældende for den udførte performance test:

• Test med begrænset datasæt; der er valgt 2 registre til testen, selvom SKRS er i stand til at udbyde flere. Alle registre bliver dog behandlet ens (med dynamisk SKRS), hvilket gør begrænsning mindre graverende for testen. Det vil dog stadig give et andet TP, da faktorer som databasen og queries af de enkelte undladte registre ikke medregnes. 
• Lokalt netværk: Alle kald til SKRS sker via et netværk der er betydeligt hurtigere end hvad man kan forvente anvendersystemer har adgang til. Dette vil samlet set betyde en længere svartid pr forespørgelse, men burde ikke påvirke TP synderligt.

Testen

Afvikling

Performance testen består af en række JMeter testplaner, samt scripts, der afvikler den valgte performancetest inkrementelt indtil det endelige throughput er fundet. For hver iteration øges enten antallet af tråde eller antallet af noder indtil det målte throughput ikke længere vokser tilsvarende.

Testplan

Testplaner anvendt i denne performance test: batchcopy

Testplanen batchcopy består af 2 dele, først en opsætningsdel der ikke tælles med i testen og derefter et antal kald til SKRS servicen. Opsætningsdelen består i at få signeret et id-kort. Selve testen består i at hente en delmængde af følgende registre ved brug af paging:

• Autorisationsregisteret: 50.000 rækker hentes op med 1000 rækker af gangen.
• Personregisteret: 500.000 rækker hentes op med 1000 rækker af gangen.

Fordeling

Fordelinger anvendt i denne performance test: test.

Fordelingen test foretager et enkelt gennemløb af de to registre.

Målinger

Throughput

De kørsler af performance testen har givet de TP der kan ses i tabellen nedenunder. Uder over TP vises også hvor mange tråde og noder der skulle til for at opnå dette TP.

Miljø

• CPU: Det lader ikke til at CPU er den begrænsende faktor her. Den vedhæftede graf viser maksimum på omkring 80 % på begge søjler. Dette kan skyldes tiden der bruges i databasen på netværket. Svarene er forholdsvist store og kunne dermed bidrage med en længere svartid.
• Heap: der ser ud til at der bliver genereret en del objekter. På den vedhæftede graf er GC tiden også vist. Denne bliver høj, dvs. der går meget tid med GC. Dette kan bidrage negativt til TP. 

Konklusion

Det forholdvist lave TP skal betragtes sammen med servicens anvendelse. Det er store datamængder, der skal transporteres samt at det oftest blot vil være et begrænset antal klienter til denne service. 

Med det målte TP bliver det til 31.428 forespørgelser i timen. I en tilfældig uge (2.dec-8.dec 2013) blev der foretaget 38.224 forespørgelser mod servicen. Se vedhæftede graf. Maks belastningen her var omkring 1.284 per time per host. Dette svarer til en udnyttelse på 8.02 %. 

Forbedringer

• Som omtalt kan GC tiden være en faktor, dermed kan det muligvis betale sig at kigge på den måde datastrukturere allokeres på i servicen.
• Da servicen opererer uafhængigt på søjlerne kan TP øges ved at tilføje yderligere søjler. Der skal dog ses på belastningen på netværket i den sammenhæng. Der køres med aktiv-passiv load-balancing på NSP, hvilket gør at alt trafik går gennem sammen LB instans. Der er dog tvivlsomt om dette er en faktor før en lang højre TP nåes.