Page History
...
Erstatnings-cpr-løsningen har følgende krav til svartider (krav 19):
|
Opsætning
Testen afvikles mod en lokalt installeret NIAB med samme komponenter som produktionsserveren (2013-10-11 - NIAB m. jboss7 uden komponenter pit20130808_01).
Svartidsmålingerne er foretaget ved klienten.
Der kan være forskel på hardware på det miljø, hvori testen er afviklet og det miljø, hvori løsningen skal deployes. Endvidere er der i disse tests minimal netværkstid, da klient og installation kører på samme maskine.
Det betyder, at disse tests kan give en god indikation af de forventede svartider samt opførsel under høj belastning. Men i praksis kan de observerede data i produktionsmiljøet afvige noget fra resultaterne af disse tests.
Afviklede tests
Det forventes, at den mest kaldte metode er GenerateReplacementCPR, hvorfor performancetesten kalder denne.
Testen er afviklet med 50.000 erstatnings-cpr-numre indsat på forhånd.
Testen er kør med følgende belastninger:
- Forventet belastning: 10 transaktioner/minut i en time. Denne test er samtidig en endurancetest, der viser, hvordan svartiderne udvikler sig under en længerevarende belastning.
- Høj belastning: 60 transaktioner/minut med sammenfaldende kald i 10 minutter
- Max belastning. Der er udført tests for at afdække ved hvilken belastning, løsningen går fra at overholde svartidskravene til ikke længere at gøre det.
Formålet med disse tests er, at sandsynliggøre, at løsningen kan leve op til de stillede krav, herunder at der ikke sker en negativ udvikling i svartiderne samt at afdække den højeste belastning, hvor løsningen stadig kan klare de stillede krav til svartider.
Resultat
Alle tider er opgivet i ms.
Forventet belastning
10 transaktioner/minut i en time. Kaldene er jævnt fordelt.
Det primære mål med denne test er dels at sandsynliggøre, at kravene til svartider kan overholdes, dels at sandsynliggøre, at svartiderne ikke udvikler sig negativt over tid.
...
Gennemsnit
...
99 percentil
...
95 percentil
...
max
...
min
...
Fejl (%)
...
Målt
...
95
...
233
...
116
...
295
...
73
...
0
...
Krav
...
1.000
...
2.000
...
1.250
...
N/A
...
N/A
...
0
...
Testdata
Byg
Opsæt
Clone performance projected
git clone https://USER@bitbucket.org/openmindsaps/performance.git
svn checkout https://svn.nspop.dk/svn/openminds/Performance/trunk
Byg med mvn clean install.
Download jmeter version 2.9 binary. Gem evt. Under c:\tools
I C:\tools\apache-jmeter-2.9\bin\user.properties skal følgende linier tilføjes. Erstat c:/dev/openminds_minlog/performance/ med stien til hvor performance projecte er tjekket ud.
search_paths=c:/Users/ole/.m2/repository/com/arosii/nsp/jmeter-minlog2/1.7.5-SNAPSHOT/jmeter-minlog2-1.7.5-SNAPSHOT.jar;c:/dev/openminds_minlog/performance/modules/jmeter-gw/target/jmeter-gw.jar;c:/dev/openminds_minlog/performance/modules/jmeter-dcc/target/jmeter-dcc.jar;c:/dev/openminds_minlog/performance/modules/jmeter-sdm/target/jmeter-sdm.jar;c:/dev/openminds_minlog/performance/modules/jmeter-sts/target/jmeter-sts.jar;c:/dev/openminds_minlog/performance/modules/jmeter-common/target/jmeter-common.jar;c:/dev/openminds_minlog/performance/modules/jmeter-minlog/target/jmeter-minlog.jar;c:/dev/openminds_minlog/performance/modules/jmeter-dds/target/jmeter-dds.jar;c:/dev/openminds_minlog/performance/modules/jmeter-consent/target/jmeter-consent.jar
Erstat c:/Users/Username/.m2/ med stien til hvor .m2 folderen er på maskinen (classpath separator på mac/linux er : ).
user.classpath=C:/Users/ole/.m2/repository/javax/javaee-api/7.0/javaee-api-7.0.jar;C:/Users/ole/.m2/repository/commons-discovery/commons-discovery/0.2/commons-discovery-0.2.jar;C:/Users/ole/.m2/repository/axis/axis/1.4/axis-1.4.jar;C:/Users/ole/.m2/repository/ca/juliusdavies/not-yet-commons-ssl/0.3.9/not-yet-commons-ssl-0.3.9.jar;C:/Users/ole/.m2/repository/org/owasp/esapi/esapi/2.0.1/esapi-2.0.1.jar;C:/Users/ole/.m2/repository/org/opensaml/openws/1.5.4/openws-1.5.4.jar;C:/Users/ole/.m2/repository/joda-time/joda-time/2.2/joda-time-2.2.jar;c:/Users/ole/.m2/repository/org/opensaml/opensaml/2.6.4/opensaml-2.6.4.jar;c:/Users/ole/.m2/repository/org/opensaml/xmltooling/1.4.4/xmltooling-1.4.4.jar;c:/Users/ole/.m2/repository/dk/sosi/seal/seal/2.4.5/seal-2.4.5-tests.jar;c:/Users/ole/.m2/repository/com/arosii/nsp/jmeter-sts/1.7.5-SNAPSHOT/jmeter-sts-1.7.5-SNAPSHOT.jar;c:/Users/ole/.m2/repository/org/apache/ws/security/wss4j/1.5.12/wss4j-1.5.12.jar;C:/Users/ole/.m2/repository/org/bouncycastle/bcprov-jdk15on/1.51/bcprov-jdk15on-1.51.jar;C:/Users/ole/.m2/repository/com/unboundid/unboundid-ldapsdk/2.3.1/unboundid-ldapsdk-2.3.1.jar;C:/Users/ole/.m2/repository/org/apache/santuario/xmlsec/1.4.8/xmlsec-1.4.8.jar;c:/Users/ole/.m2/repository/com/arosii/nsp/jmeter-minlog2/1.7.5-SNAPSHOT/jmeter-minlog2-1.7.5-SNAPSHOT.jar;c:/Users/ole/.m2/repository/dk/sosi/seal/seal/2.4.5/seal-2.4.5.jar;c:/Users/ole/.m2/repository/dk/sosi/testtools/testtools/2.4.5/testtools-2.4.5.jar;C:/Users/ole/.m2/repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar;C:/Users/ole/.m2/repository/org/antlr/stringtemplate/4.0.2/stringtemplate-4.0.2.jar;c:/Users/ole/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar;c:/Users/ole/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar;
Nu kan jmeter startes vha. C:\tools\apache-jmeter-2.9\bin\jmeter.bat eller ./jmeter.sh
Der er fire test templates
Performance tests
Lookup.
Der er lavet en LookupRequestSampler. Den tager et cpr som input og forventer der er et IDCard på threadcontexten. Med inputtet laver den et kald til GetLogStatementsForCPRPerson.
Se eksemplet her.
tests/minlog2/src/test/jmeter/templates/testplans/lookup.template.jmx
Lookup on behalf of
Her laves der lookup on behalf of hvor man enten benytter et medarbejder certifikat eller et firmacertifikat.
I setup fasen indhentes certifikatet og herefter startes selve performance testen.
Lookup on behalf of sampleren tager et cpr som input. Så det er muligt at sætte testen op så man indlæser en fil med flere cprnumre og bruger forskellige hver gang et kald laves.
Vi har lavet et eksempel på hvordan det kan sættes op her.
tests/minlog2/src/test/jmeter/templates/testplans/lookup_onbehalfof.template.jmx
Lookupid.
Under setup hentes der nemind certifikater for de test brugere der benyttes. Lookupidentitytoken sampleren tager cpr, procurator cpr og subject som input. De nemid certifikater der hentes ind gemmes i et statisk map så de kan genbruges af lookupid sampleren i selve performance testen.
Lookupidws sampleren tager et cpr som input. Den bruger cpr til at hente certifikatet fra setup af og laver hefterter et kald til minlog2 hvor certifikatet benyttes.
Vi har lavet et eksempel på hvordan det kan sættes op her.
tests/minlog2/src/test/jmeter/templates/testplans/lookupidws.template.jmx
Registration
Vi har lavet et eksempel på hvordan det kan sættes op her.
tests/minlog2/src/test/jmeter/templates/testplans/registration.template.jmx
...
Høj belastning
60 transaktioner/minut med sammenfaldende kald i 10 minutter.
Denne belasting er 6 gange den forventede.
Formålet med denne test er at undersøge, hvordan svartiderne udvikler sig, hvis belastning øges til et niveau, der er markant højere end det forventede.
...
Gennemsnit
...
99 percentil
...
95 percentil
...
max
...
min
...
Fejl (%)
...
98
...
138
...
126
...
218
...
72
...
0
...
Svartiderne her ligner meget svartiderne ved den forventede belastning, selv om der er en belastning, der er 6 gange større.
Max belastning
I forsøg på at afdække ved hvilken belastning, løsningen ikke længere kan leve op til kravene, er der udført to tests med belastninger tæt på hinanden, men hvor der er markant forskel på svartiderne.
- 1200 transaktioner/minut i ca. 5 minutter
b. 1500 transaktioner/minut i ca. 5 minutter
...
Gennemsnit
...
99 percentil
...
95 percentil
...
max
...
min
...
Fejl (%)
...
a.
...
238
...
1.084
...
589
...
2.881
...
87
...
0
...
b.
...
1.147
...
2.385
...
1.942
...
3.847
...
84
...
0
...
Figur 4 Svartidsfordeling a. En markant top omkring 200 m
Figur 5 Svartidsudvikling b. Kaldene fordeler sig omkring 1.000 ms.
Det er markant at svartids billedet er forskudt med omkring 800 ms trods det, at belastningen kun er øget 25 % fra a. til b. Det tyder på, at applikationen bliver presset ved omkring 20-25 kald/sekund.
Konklusion
Ved den forventede belastning ligger svartiderne meget langt under de opstillede krav. Ved en belastning, der er 10 gange så stor som den forventede, er svartiden stort set uændret. I begge tilfælde ligger svartiderne nede omkring en tiendedel af kravet.
Afsøgning af den maksimale belastning viser, at løsningen kan overholde svartiden, når belastningen er under ca. 1.200 kald i minuttet – eller ca. 120 gange det forventede. Om det præcist er, hvad løsningen kan håndtere i produktion er det useriøst at udtale sig om. Dog er det sandsynligt, at løsningen kan håndtere markant mere det forventede.
Desuden er det værd at notere sig, at der stadig ikke er kald, der fejler selv om de øgede svartider indikerer, at serveren er lidt presset.
Sammenfattende indikerer performancetesten, at der ikke kan forventes problemer med at leve op til svartiderne.