...

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

...

SAES

SCES, Stamdata CPR Enkeltopslags Servicen, bruges til at hente informationer fra bla. CPR registreret ud. Servicen har et antalt web services, som har forskellig funktionalitet. i denne test er det operationerne "GetPersonDetails" og "DetGodeCPROpslag" der anvendes.

SCES er del af SDM leverancen. Til testen er SDM 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 blevet brugt. 

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
• Begrænset delmængde af datasættet. Som det beskrives senere så testet ikke med alle mulige CPR numre, men med mindre delmængde. Valget her er baseret på udhentning via SKRS. Dette kan påvirke hvor hurtigt databasen tilbyder data.
• Alle kald til SKRS sker via et lokalt 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.

...

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: personlookupauthorization

Testplanen personlookupauthorization består af 2 dele, først en opsætningsdel der ikke tælles med i testen og derefter et antal kald til SCES 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 persondetaljer autorisationerne for et antal tilfældigt udvalgte personnumre. For hver gennemløb i testen hentes der persondetaljer på følgende måder:

...

• A ud af 100 gange hentes der personoplysninger inklusiv oplysninger om egen læge
• B ud af 100 gange hentes der personoplysninger uden oplysninger om egen læge

...

• A ud af 100 gange hentes der personoplysninger inklusiv oplysninger om egen læge
• B ud af 100 gange hentes der personoplysninger uden oplysninger om egen læge

...

personer

...

.

...

Hvert gennemløb foretages N gange.

Fordeling

Fordelinger anvendt i denne performance test: prodtest.

Fordelingen prod foretager 2000 (N) gennemløb af testplanen, 99% (X) opslag mod "DetGodeCPROpslag v. 1.0.2", 0.5% (Y) opslag mod "DetGodeCPROpslag v. 1.0.0" og 0.5% (Z) opslag mod "GetPersonDetails". 90% (A) af opslag mod "DetGodeCPROpslag" sker med information om egen læge og 10% (B) uden.Disse fordelinger er baseret på observationer af produktion i en tilfældig uge (24. marts 2014 til 31. marts 2014)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. Derudover er fejlraten medtaget, da denne i en tidligere test udgjorde en betydelig andel.

Miljø

• CPU: CPU ser ikke ud til at være en begrænsende faktor. På grafen ses at der i store dele af testen, er en belastning på mellem 80% og 90% på begge søjler, 100% belastning rammes kun en enkelt gang under forløbet.
• Heap: På vedhæftede graf er der intet usædvanligt at bemærke. Det vurderes at hverken GC tid eller størrelse af heap har nogen speciel indvirkning på TP.

Observerede fejl

De ca 0.04% fejl der er i hver gennemløb af testen udgør så lille en fejlrate at de ikke kan have haft en indvirkning på TP.

Konklusion

...

• 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 (24. marts 2014 til 31. marts 20142.-8.dec 2013) blev der dog foretaget 45114.335 937 forespørgelser med et anormalt peak den 25. mar kl. 11 på omkring 22.000 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 7561.342.000 944 forespørgelser i timen. I den undersøgte tid udnyttes servicen dermed maksimalt med 2.91%

Forbedringer

• Antallet af søjler kan forøge TP. Dette er baseret på viden om at servicen agere uafhængigt af andre søjler. 

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.