Page History
| Anchor | ||||
|---|---|---|---|---|
|
Performancetest1
Indhold2
Indledning3
Krav3
Opsætning3
Afviklede tests3
Resultat4
Forventet belastning4
Høj belastning5
Max belastning6
Konklusion7
...
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.
...
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:
...
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.
...
De målte værdier ligger komfortabelt under de stillede krav – i runde tal ca. en tiendedel. Det ses desuden af grafen nedenfor, at svartiderne ikke udvikler sig.
Figur 1 Svartidsudvilking ved forventet belastning. Der er ingen indikationer af, at svartiden ændrer sig i løbet af den time testen står på.
Figur 2 Percentiler ved forventet belastning. En meget flad kurve, der indikerer ret lille variation i svartiden.
| Anchor | ||
|---|---|---|
|
...
| Anchor | |||
|---|---|---|---|
|
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 |
Figur 3 Næsten alle svar ligger stadig under 200 ms.
Svartiderne her ligner meget svartiderne ved den forventede belastning, selv om der er en belastning, der er 6 gange større.
...
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
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.