Page History

...

• SOSI-GW testklient, der kalder SOSI-GW services og kalder en test -service gennem SOSI-GW proxy-metoden.
  1. Testklienten kan konfigureres gennem Jmeters GUI, så den kan benyttes til flere forskellige slags test.

...

• 1. 1. Navne på SOSI-GW hosts, der skal være del af samme SOSI-GW cluster. 

...

• 1. 1. Størrelsen på svaret fra testservicen.

...

• 1. 1. Ventetiden i testservicen, til at simulere lang svartid fra servicen.

...

• 1. 1. Mængden af ID-kort den holder fast i, i sin cache.

...

• 1. 1. Hvor ofte den skal gennemføre logout /login på eksisterende ID-kort i cachen

...

• 1. 1. Hvor ofte den skal erstatte et ID-kort med et nyt, uden at kalde logut på det gamle.

...

• 1. Testklienten vælger ved hvert kald til SOSI-GW en tilfældig sosigwserver. Hvis kaldet fejler med socket- niveau fejl, prøver den de andre efter tur. Hvis det ikke lykkes på nogen af dem, fejler kaldet. Dette simulerer brug af en loadbalancer, der ikke vedligeholder nogen tilstand for klienterne og som sørger for at benytte en anden server når den valgte server ikke svarer. Bemærk at dette valg stresser intra- cluster kommunikationen rigtig meget. Den er ikke altid er hurtig nok til at et login mod en server er propageret til samtlige andre servere, inden klienten forsøger at benytte proxy mod en anden server. Klienten vil dermed få implicit login i denne situation, hvilket den opfatter som en fejl. For at modvirke dette kan SOSI-GW konfigureres til at vente et stykke tid, før den svarer med implicit-login, mens den venter på at idkortet ankommer. I testresultaterne kan det ses dels som fejl-procent, når det ikke når frem, og dels som øget svartid. I virkeligheden vil denne situation kun opstå, hvis man benytter klienter, der fuldautomatisk underskriver id-kortet på brugerens vegne på ganske få millisekunder. (Det ville have været let at løse i testklienten, hvis ikke implicit-login havde eksisteret: man kunne bare prøve igen, eller prøve den næste server. Men implicit login nulstiller ens ID-kort, så det skal underskrives igen.)

• Jakarta JMeter v2.3.1 som test - driver og analyseværktøj for nogle af resultaterne
  1. Java Sampler med førnævnte testklient.

...

• 1. HTTP Request kan benyttes til at stresse dele af browser-baseret login, men ikke hele forløbet, da den ikke kan udføre den applet, der udgør den reelle login. Den kan dog benyttes til at belaste serveren svarende til belastningen af klienter, der ikke tidligere har downloadet applet'en fra serveren.

• Trifork P4 v4.0.1 som måleværktøj til at analysere fordelingen af svartiden internt i SOSI-GW. Som kravene til SOSI-GW er beskrevet, er det nødvendigt at skelne mellem tid brugt i SOSI-GW og tid brugt i test servicen. (Som resultaterne er faldet ud, har denne del ikek været nødvendig og er undladt.)
  
  
• Trifork T4 v4.1.29 som omgivelse for SOSI-GW. Denne foretrækkes frem for Tomcat på grund af den indbyggede monitorering af memory og tråde.
  
  
• Windows XP på forskelligt bestykkede maskiner:
  1. sosigw01: AMD Sempron 2800+ @1.60GHz 1.0GB RAM.

...

• 1. 1. Trifork T4 med sosigw-testservice.war.

...

• 1. 1. PostgreSQL med den globale audit- log database.

...

• 1. sosigw02, sosigw03, sosigw04: AMD Sempron 2400+ @1.66GHz 1.5GB

...

• 1. RAM

...

• 1. 1. SOSI-GW cluster medlemmer

...

• 1. 1. Alternativt: Trifork T4 med sosigw-testservice.war.

...

• 1. sosigw05, sosigw06: AMD Sempron 2400+ @1.66GHz 1.5GB RAM

...

• 1. 1. JMeter testklienter.

...

• 1. 1. Alternativt: SOSI-GW cluster medlemmer
        
        
• Mellem testmaskinerne er der et 100 Mbit switched netværk.

Alle tests foretages med et cluster- setup, da det er den anbefalede og forventede driftform. Der er også en større del af systemet involveret i testen på denne måde.

Relation til krav

\[Krav 26\] til SOSI-GW udtaler sig om svartider for proxy-metoden, og da det er den brugerne vil bemærke svartiden af, hvis den overstiger kravene, er det denne, der testes og måles på. Der udføres også kald til de øvrige services på SOSI-GW, men tiderne for disse måles ikke. De indgår dog som belastning på maskinen og påvirker dermed throughput for proxy-metoden.
\[Krav 25\] og \[krav 27\] har svartidskrav på 5 hhv. 10 sekunder. Disse er så høje, samtidig med at testscenarierne er mere komplekse, at det er mere fordelagtigt at foretage tests af dem med håndkraft.

Skaleringstest

Skaleringstesten foretages ved at måle responstiden i klienten ved forskellige grader af belastning, og verificere at denne ikke stiger mere end proportionalt med belastningen. Det totale throughput ved de forskellige belastningsgrader måles.
Testen er afviklet med følgende parametre:

...

Under testen registreres responstiden, som den ses af testklienten. Den måles altså inklusiv al netværkstransport og det ene sekunds forsinkelse, som testservicen lægger på.

Resultater

23377101410151031103110321047

1. 6602102510161031103212811422
2. 8294105210161094139014221453
3. 9922102310151031104613281437

 813363103510161032111014211453
 1016481104010161047120314221469
 1626179105110161125135914691500
 2032573106510161219139114851531
 3048017108710311313146915321579
 4062546113710471453156316871781
 5075881119610781578173419062000
 6086242130311871766193821252297
 7095933141912972016223423902531
 80103421153814532172237527972985
 90109505168716092407268830003250
 100110599190418132781307833443641
 110117367203519842953318835003688
 120121522218521253156340637184079
 130119844243123913282356238914187
 140121918262725633500381342974593
 150102600359234854984540662347265
 160 97654415940785391589177038719
Cluster med to servere, hvoraf kun en benyttes
!worddavbec34212c9061afc4b53b09f79d681bd.png|height=233,width=522!Responstid i ms.50% fraktil
90% fraktil
95% fraktil
98% fraktil
99% fraktil
Gennemsnit
Kald / time
 2456810 16 20 3040 50 60 70 80 90 100110120 130140150160
Antal test­tråde
Målingerne for de små belastninger skæmmes af at JMeter benytter en timer, der på Windows kun har en opløsning på ca. 15ms. Bemærk også at målingerne indeholder ventetiden i test - servicen på 1000 ms, samt test - servicens øvrige tid, samt al netværkstid. Det betyder at der skal trækkes 1000 ms fra alle målinger for at finde frem til tiden brugt i SOSI-GW, inkl. netværkstid.
Relativt til \[Krav 26\] er det meget fine tal. Kravet omtaler gennemsnit- og fraktiltider for proxy-kaldet ved gennemførelse af 10.000 proxy-kald pr. time, fraregnet al netværkstid.

• Gennemsnit < 500ms. Dette er til fulde opfyldt for den krævede belastning på 10.000 kald pr. time, med en værdi på 35ms for 13.363 kald pr. time.
• 95 % fraktilen < 1 sekund. Ved 13.363 kald pr. time nåede den op på 110 ms.
• 99 % fraktilen < 4 sekunder. Ved 13.363 kald pr. time nåede den op på 453 ms.

Samlet set er der rigeligt skalerbarhed til at nå målene i krav-specifikationen. Svartidskravene er opfyldt op til 86.242 kald pr. time, hvor 95% fraktilen nærmer sig 1 sekund. Omkring 120.000 kald pr. time er det maksimale, der kan presses igennem denne testserver, men over 90.000 kald pr. time vokser svartiderne ud over det acceptable.

Loadbalancering

Loadbalancering aftestes i et miljø med 2 gateway servere. Dette foretages ved at gentage skaleringstesten med 2 aktive servere i clusteret. Det verificeres at overbelastningspunktet øges i forhold til et miljø bestående af kun én server. Det må forventes, at gevinsten ved at tilføje en server vil være mindre end liniær.
Testen er afviklet med samme parametre som skaleringstesten, undtagen:
● Clusteret består af de to medlemmer, der begge benyttes til kald.
Vi ønsker her at afprøve om det er muligt at gennemføre flere proxy-kald med lavere svartider ved at benytte flere servere i clusteret. Bemærk at der er de samme medlemmer af clusteret som før, og at det derfor udelukkende er kaldsmønsteret, der er ændret. Clustermedlemmerne har samme overhead ved at holde hinanden orienteret om den fælles tilstand som i skaleringstesten, omend trafikken nu går begge veje.

Resultater

Cluster med to servere, hvoraf kun en benyttes

Image Added

Målingerne for de små belastninger skæmmes af at JMeter benytter en timer, der på Windows kun har en opløsning på ca. 15ms. Bemærk også at målingerne indeholder ventetiden i test - servicen på 1000 ms, samt test - servicens øvrige tid, samt al netværkstid. Det betyder at der skal trækkes 1000 ms fra alle målinger for at finde frem til tiden brugt i SOSI-GW, inkl. netværkstid.
Relativt til \[Krav 26\] er det meget fine tal. Kravet omtaler gennemsnit- og fraktiltider for proxy-kaldet ved gennemførelse af 10.000 proxy-kald pr. time, fraregnet al netværkstid.

• Gennemsnit < 500ms. Dette er til fulde opfyldt for den krævede belastning på 10.000 kald pr. time, med en værdi på 35ms for 13.363 kald pr. time.
• 95 % fraktilen < 1 sekund. Ved 13.363 kald pr. time nåede den op på 110 ms.
• 99 % fraktilen < 4 sekunder. Ved 13.363 kald pr. time nåede den op på 453 ms.

Samlet set er der rigeligt skalerbarhed til at nå målene i krav-specifikationen. Svartidskravene er opfyldt op til 86.242 kald pr. time, hvor 95% fraktilen nærmer sig 1 sekund. Omkring 120.000 kald pr. time er det maksimale, der kan presses igennem denne testserver, men over 90.000 kald pr. time vokser svartiderne ud over det acceptable.

Loadbalancering

Loadbalancering aftestes i et miljø med 2 gateway servere. Dette foretages ved at gentage skaleringstesten med 2 aktive servere i clusteret.
Det verificeres at overbelastningspunktet øges i forhold til et miljø bestående af kun én server. Det må forventes, at gevinsten ved at tilføje en server vil være mindre end liniær.
Testen er afviklet med samme parametre som skaleringstesten, undtagen:

● Clusteret består af de to medlemmer, der begge benyttes til kald.
Vi ønsker her at afprøve om det er muligt at gennemføre flere proxy-kald med lavere svartider ved at benytte flere servere i clusteret. Bemærk at der er de samme medlemmer af clusteret som før, og at det derfor udelukkende er kaldsmønsteret, der er ændret. Clustermedlemmerne har samme overhead ved at holde hinanden orienteret om den fælles tilstand som i skaleringstesten, omend trafikken nu går begge veje.

Resultater

Cluster med to servere, der begge benyttes

Image Added10168841012101510161031103210470.00%
20334441019101510311032110913900.00%
30495721027101510321063139015000.00%
40660671033101610471109140615310.04%
50819941057101611091343156216410.00%
60963001076101612181469165617650.01%
701113981099103113131547173518590.00%
801242221132104614221672187520310.01%
901361881181106215931797201621720.00%
1001481761210107816251875210922500.02%
1101536261308112518902172248426250.10%
1201697331364118819842250254727190.00%
1301724111424126620632328260928120.00%
140171634155814532266256328903109 0.15%
1501873151605146823292687300032190.06%
1601891011736160925152875337535940.08%
1701880421766159426723047345336400.31%
1801917291823164127503125351636880.41%
1902039981896175028123156353238750.10%
2002008731995179730933500381340780.29%
2202140562040182831873641409444220.65%
2402105282031185931093531390641871.17%
2602135382200200034533906435947341.29%
2802189162239 204734223906448549851.43%
3002088072144195332973750429747662.53%
3202179302455218839694547507854372.19%
Cluster med to servere, der begge benyttes
!worddav29c434c9404e275c3e31847fbd8f0c11.png|height=253,width=543!Responstid i ms.50% fraktil
90% fraktil
95% fraktil 98% fraktil
99% fraktil
Gennemsnit
Kald / time
20406080100120140160180200240280320
1030507090110130150170190220260300
Antal test­tråde

Bemærk at grafen her og i skaleringstest- afsnittet har forskellige skalaer på de begge akser og dermed skal sammenlignes med varsomhed. Ved omkring 150.000
kald pr. time rammer 95% fraktilen grænsen på 1 sekund. Det er en klar forbedring over de ca. 90.000 fra enkelt-server testen. Det er muligt at gennemføre omkring 210.000 kald pr. time i denne konfiguration, med acceptable svartider, der dog ikke lever op til kravet til 95% fraktilen.
Ved belastning over 150.000 kald pr. time begynder der at opstå fejl, som det ses af søjlen Fejl rate . Denne angiver hvor mange kald, der fejlede ud af det totale antal, der er forsøgt gennemført. Fejlene består i, at der rammes en anden server efter et login, og at denne endnu ikke kender id-kortet, hvorfor den svarer implicit login.

...

Vi sammenligner her resultaterne af skaleringstesten for 60 tråde med loadbalanceringstesten for 60 tråde. De 60 tråde er den højest målte belastning, hvor svartiderne overholdes i skaleringstesten.

...

Det samme antal tråde når at gennemføre flere kald på grund af den gennemgående lavere svartid. Gennemsnitssvartiden falder fra 303 ms til 76 ms, mens 95% fraktilen halveres fra 938 ms til 469 ms. Der altså en markant forbedring i svartid for brugerne ved at benytte to servere frem for en.
Loadbalancering af SOSI­GW

Blå grafer viser én server, røde viser to.
Image Modified
Denne graf viser hvordan svartiderne udvikler sig i skaleringstesten og loadbalanceringstesten. Det ses at det er muligt at have væsentligt større belastning med rimelige svartider ved to servere i forhold til en. I den følgende graf ses det at der også ved lavere belastninger er en genvist ved at benytte to servere frem for en, idet det er muligt at holde 99% fraktilen meget lavere. Loadbalancering af SOSI­GW

Blå grafer viser én server, røde viser to.
050001000015000200002500030000350001000110012001300140015001600Enkelt gennemsnitEnkelt 99% fraktilDual gennemsnitDual 99% fraktilThroughput (Kald pr. time)Responstid i msImage Added

Load/stresstest

I forlængelse af skaleringstesten fastslås den belastningsgrad hvor throughput ikke længere stiger som funktion af antal afsendte requests. Det verificeres, at overbelastning ikke fører til fejlbehandlede requests samt at systemet efterfølgende kommer sig uden nogen blivende degradering. I praksis udføres denne test ved at udføre loadbalanceringstesten med noget højere belastning end den viste sig at kunne bære, og derefter udføre samme tests lave belastninger. Derefter sammenlignes resultatet med resultatet fra loadbalanceringstesten og det verificeres at der ikke forekommer fejl, samt at svartiden falder i takt med belastningen, til samme niveau som før overbelastningen. 1500025000350004500055000650007500085000950001000120014001600180020002200Svartider

Svartider før og efter stress testGennemsnit, før95% fraktil, før99% fraktil, førGennemsnit, efter95% fraktil, efter99% fraktil, efterthroughput, kald pr. timeResponstid i mstest

Image Added

Grafen viser resultatet at gennemføre den samme test før og efter en kørsel med markant overbelastning. Der ses stort set uændrede gennemsnitlige svartider og throughput, mens 99% fraktilerne varierer lidt mere kaotisk, uden at der er nogen markant forskel. 95% fraktilen er lidt lavere efter stress - perioden end før, men ikke markant. Konklusionen er at der ikke er nogen blivende eftervirkning af en stress - pediode at spore.

Endurancetest

Endurancetest foretages ved en længerevarende test, hvor testklienten konfigureres til en belastningsgrad, der ligger et stykke under det overbelastningspunkt, der er identificeret under load /stresstesten. Under endurancetest overvåges memoryforbrug, antal tråde, og CPU forbrug. 
Testen er afviklet med følgende parametre, der er valgt til at ramme den beskrevne belastning i \[krav 26\], som er 10.000 proxy-kald i timen (166 i minuttet), samtidig med 1000 login- kald i timen. (17 i minuttet)

• 100 tråde
• Der ventes 8 sekunder mellem kaldene.
• Test-servicen venter 10 sekunder før den svarer med et svar, som er en streng på 4096 tegn, pakket ind i SOAP-transport. Der sendes også en 4096 tegns streng med hvert kald.

• Hver tråd ventes af tage lidt over 10 sekunder i alt på kaldene. Med i alt 18 sekunder pr kald kan en tråd nå 3600/18=200 kald i timen. Med 100 tråde ventes dermed op mod 100*200=20.000 kald i timen. I praksis ventes mellem 19.000 og 20.000
• Hver tråd har et ID-kort. Hver tråd laver login uden at kalde logout på det gamle kort ved 5% af kaldene til proxy. Dette har den effekt at der i løbet af 24 timers kørsel skabes omkring 5% * 20.000 * 24 = 24.000 id-kort i cachen på SOSI-GW. Derefter vil de ældste af dem blive fjernet af cachen selv, efterhånden som de overskrider deres maksimale levetid på 24 timer.
• Testen køres i minimum 24 timer. De første 24 - 25 timer forventes resourceforbruget at vokse støt på grund af den tiltagende mængde id-kort i cachen, hvorefter det bør stabilisere sig. Der bør ikke være nogen nævneværdig ændring i svartiderne hen over perioden, omend der ventes en lille effekt af at have så mange ID-kort.
• Der forventes et memoryforbrug på omkring 32kb pr. id-kort, altså i alt omkring 768 MB heap til id-kort. Tallet er anslået ved at måle gennemsnitsstørrelsen af et ID-kort med Trifork P4. Det forholdsvis store forbrug skyldes at en id-kort instans, som den er i SEAL, indeholder en DOM repræsentation, der fylder temmelig meget. Oven i det kommer at den også gemmes serialiseret som XML-streng, hvad der fylder omkring 6kb, af hensyn til at kunnesende den til andre medlemmer i clusteret. Man kunne nøjes med at have den serialiserede udgave af hensyn til plads, men det er ikke en tids - effektiv måde at opbevare den på, da det så skulle parses ved hvert proxy-kald.
• For at validere at forældelse af gamle kort fungerer, køres i fortsættelse en test, hvor der foretages meget færre logins og ellers benyttes samme parametre. I praksis er valgt at lave login i 1% af kaldene, og samtidig foretage logout på det gamle nameID ved gen - login, så der ikke ophobes ret mange id-kort. Efter et døgn bør der være 100 id-kort i cachen, samt oplysninger om 1% * 20.000 * 24 = 4.800 brugte nameID'er med status REVOKED.
• For at teste cluster- delen mest muligt, benyttes 4 servere i clusteret i denne test. Der er kun behov for én maskine til test -servicen og én til at drive testen med denne lave belastning.

...

Der er kørt med den ovennævnte høje belastning i 40 timer, og derefter en lille uges tid med den lavere belastning. Her er grafer og memoryforbrug og svartider i denne periode. Svatiderne er for perioden med den høje belastning.



Svartider, set for hver time Image Removed ms
0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930313233343536373839
Time i endurance­testen

Image Added

Der ses det forventede forløb i heap - udviklingen, nemlig en kraftig stigning de første 24 timer og derefter en kurve hvis bund er vandret , med den nøjagtighed det kan afgøres her. Der er gennemført 797513 kald i alt i løbet af de 40 timer, svarende til 19938 kald pr. time i gennemsnit. Heraf gav de 3 fejl tilbage til klienten, og i alle tre tilfælde er der tale om at testklienten ikke kunne gennemføre socketforbindelsen til SOSI-GW-servicen.
For at teste synkroniseringsmekanismen startes en ekstra server efter ca. 41 timers test. Denne server modtager tilstanden fra en af de eksisterende. Den modtog 122MB data i løbet af 37 sekunder, og det bestod af 22561 id-kort. Afsendelsen af disse data belastede den afsendende server med ca. 20% cpu, så den i alt var omkring 25% belastet.
Efterfølgende har clusteret af nu 4 servere fået lov at køre i en lille uges tid for at se heap - grafen for en længere periode. Den har et uproblematisk forløb.
CPU-forbruget er under testen næsten ikke målbart. Windos taskmanager viser det typisk som 2 - 5%.
Trådpoolen i T4 er sat til max 400 http - tråde . Som det ses af følgende graf er der højst benyttet 150 i VM'ens levetid, og under endurance-testen er der omkring 20- 30 i brug i gennemsnit. Dette svarer med forventningerne, da der er 100 testtråde, hvis kald skal fordeles over 4 servere.

...