Page History
...
| Application server | Iteration | Antal kald | Kald per sekund | Tidsforbrug (sekund) | Kald >= 6,5 sekund | Kald >=15,5 sekund |
|---|---|---|---|---|---|---|
| docker01.cnsp.stage.nsp.netic.dk | 1 | 419 | 1,40 | 3,25 | 10 = 2,39 % | 0 = 0 % |
| 2 | 634 | 2,11 | 3,42 | 15 = 2,37 % | 0 = 0 % | |
| 3 | 640 | 2,13 | 4,69 | 94 = 14,69 % | 0 = 0 % | |
| 4 | 1089 | 3,63 | 4,12 | 20 = 1,84 % | 0 = 0 % | |
| 5 | 954 | 3,18 | 6,23 | 372 = 38,99 % | 0 = 0 % | |
| docker02.cnsp.stage.nsp.netic.dk | 1 | 418 | 1,39 | 3,26 | 8 = 1,91 % | 0 = 0 % |
| 2 | 634 | 2,11 | 3,45 | 11 = 1,74 % | 0 = 0 % | |
| 3 | 644 | 2,15 | 4,68 | 91 = 14,13 % | 0 = 0 % | |
| 4 | 1090 | 3,63 | 4,16 | 17 = 1,56 % | 0 = 0 % | |
| 5 | 955 | 3,18 | 6,38 | 412 = 43,14 % | 0 = 0 % | |
| Total | 7477 | 4,57 | 1050 = 14,04 % | 0 = 0 % |
Udtræk af svartid og antal kald fordelt over testens løbetid vises i følgende grafer:
Data serier i grafen er:
- NoOfCalls (rød): det gennemsnitlige antal kald hvert minut
- De 5 iterationer (sort) er baseret på det tidstempel, som findes i access loggen
...
Registration komponenten er I de sidste iterationer oppe at bruge 75-80 % af CPU’en. Og sammenligner man med den sidste performance test, ligger den noget højere. Men der skal også for hvert kald nu håndteres 500 registreringer mod før 1. Men der er stadig processer kraft til overs.
Jstat log
Denne log findes for hver applikations server (docker container). Både for registration og kafka-consumer. Loggen viser resultatet af kommandoen jstat. Jstat siger noget om, hvordan JVM'en har det.
Udtræk omkring hukommelse og garbage collection fra denne log vises i de følgende grafer:
Data serier i grafen er:
- YGC (rød): young generation garbage collection events, antal af "ung" garbage collection siden start
- FGC (blå): full garbage collection events, antal af fuldstændig garbage collection siden start
- HeapU (gul): består af S0U+S1U+EU fra jstat loggen. Young generation memory utilization. "Ung" hukommelses forbrug
- HeapC (grøn): består af S0C+S1C+EC fra jstat loggen. Young generation memory capacity. "Ung" hukommelses kapacitet
- OU_MB (pink): old space utilization. "Ældre" hukommelses forbrug
- OC_MB (tyrkis): old space capacity. "Ældre" hukommelses kapacitet er konstant på 1.398.272 KB.
- Iterationer (sort) er baseret på det tidstempel, som findes i jstatloggen
Registration:
- Der er en svag stigning I full garbage collection (FGC). Kigger man nærmere på datagrundlaget bag graferne, ses det, at der kørt full garbage collection for servicen under testen 32 (docker01) henholdsvis 33 (docker02) gange i starten af første iteration.
- Den ældre hukommelse (OU_MB) ligger og svinger op og ned mens garbage collectoren holder den I skak, så den aldrig når sit maks (OC_MB)
- Der køres ofte garbage collection på den yngre hukommelse, hvilket holder HeapU - yngre hukommelses forbrug - nede så den kun svinger inden for et konstant interval.
Kafka-consumer:
- Her er der ikke kørt fuld garbage collecion (FGC) under testen.
- Der er ikke brug for at køre meget garbage collection på den yngre hukommelse, og den yngre hukommelse (HeapU) holdes nede. Der ses dog et forskelligt mønster for de 2 servers yngre hukommelse, hvor der køres dobbelt så meget carbage collection på docker02, med dertilhørende oftere udsving I HeapU.
Vurdering
Både den yngre og ældre forbrugte hukommelse eksalerer ikke. Garbage collecterne gør sit arbejde. Noget kunne tyde på, at kafka-consumer docker02 laver noget mere end docker01.
Docker stats log
Vurdering
...