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

SAES

Stamdata autorisation enkeltopslagsservice (SAES) udstiller en service som anvendere af NSP kan bruge til at slå autorisationer op med. Der er foretaget målinger af Throughput (TP) på et staging miljø opsat af Netic. Målingerne er foretaget i løbet af december måned 2013 på SDM version 3.5.8.

Antagelser og forbehold

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

• Fordeling:SAES bestør kun af en enkelt service, men den kræver et personnummer for at kunne kaldes. Performance testen starter derfor med at hente op til 25.000 personer ud via kopiregisterservicen. Dette kan påvirke caching i databasen mv.
• Lokalt netværk: Alle kald til SAES 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.

Følgende tests er blevet afviklet:

Testplan

Testplaner anvendt i denne performance test: authorization

Testplanen authorization består af 2 dele, først en opsætningsdel der ikke tælles med i testen og derefter et antal kald til SAES servicen. Opsætningsdelen består i at få signeret et id-kort og derefter hente op til 25.000 personer ud fra SDM via SKRS. Selve testen består i at hente autorisationerne for et antal tilfældigt udvalgte personer.

Fordeling

Fordelinger anvendt i denne performance test: test.

Fordelingen test foretager 1000 kald til SAES

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: Kørslerne udnytter fuldt CPU'erne. Dette kan ses på den vedhæftede graf, hvor toppene svarer til varigheden af kørslerne.  
• Heap: Der bruges en del hukommelse, som skal ryddes op igen. Dette kan måske afhjælpes ved at optimere på de anvendte datastrukture. Om dette har en stor betydning på TP er svært at bestemme uden yderligere analyser og testkørsler. På den vedhæftede graf er garbage collection tiden medtaget og PermGen space er separeret fra øvrig heap.  

Konklusion

I en tilfældig uge (2.-8.dec 2013) blev der dog foretaget 14.937 forespørgelser med et anomalt peak fra 4. dec kl. 17 til 5. dec kl. 2 på omkring 600 kald i timen.

Med det målte TP bliver det 1.342.944 forespørgelser i timen. I den undersøgte tid udnyttes servicen dermed med 0.44 ‰. 

Forbedringer

• Hukommelse: det er muligt GC (memory oprydning) tiden kan nedbringes ved at kigge på servicens datastrukture. 
• Miljø: da servicen arbejder isoleret på en søjle, kan TP forøges ved at sætte flere søjler op.