Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Anchor | ||||
|---|---|---|---|---|
|
...
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
| Wiki Markup |
|---|
\[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
Antal tråde | Kald / time | Gennemsn |
23377101410151031103110321047
- 6602102510161031103212811422
- 8294105210161094139014221453
- 9922102310151031104613281437
| Wiki Markup |
|---|
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 testtrå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.
...
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
Antal tråde | Kald / time | Gennemsn 50% | 90% | 95% | 98% | 99% | Fejl rate |
10168841012101510161031103210470.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 testtrå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.
Antal aktive servere | Kald / time | Gennemsn |
- 86242130311871766193821252297
- 96300107610161218146916561765
...
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 før og efter stress testGennemsnit, før95% fraktil, før99% fraktil, førGennemsnit, efter95% fraktil, efter99% fraktil, efterthroughput, kald pr. timeResponstid i ms
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
| Wiki Markup |
|---|
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
...