tormakris/knative-report-latex
1
0
Fork 0
Code Issues Pull Requests Releases Activity

text about coldstart mérés

Browse Source
This commit is contained in:
Torma Kristóf 2019-12-07 00:23:14 +01:00
parent 049a887ae7
commit 700cc4970c
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
2 changed files with 9 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
src/content/preparation.tex
View File

@ -99,6 +99,9 @@ A folyamatos terhel\'est gener\'al\'o m\'er\'es \aref{code:bash-banchmark-for} k
Mint az \aref{code:bash-banchmark-climb} kódrészleten látszik, a növekvő terhelésű mérés implementációja igen hasonló az egyenletes terhelésűhöz. A hey működését kihasználva, a –rps kapcsoló segítségével beállított limit nem változik a mérés során, csupán a connection objektumok száma emelkedik. Mint az \aref{code:bash-banchmark-climb} kódrészleten látszik, a növekvő terhelésű mérés implementációja igen hasonló az egyenletes terhelésűhöz. A hey működését kihasználva, a –rps kapcsoló segítségével beállított limit nem változik a mérés során, csupán a connection objektumok száma emelkedik.
\section{Null\'ara sk\'al\'az\'as eset\'eben v\'alaszidő m\'er\'ese}
Teljesen m\'ashogy kell m\'erni azt, hogy mik\'ent alakul a v\'alaszideje a f\"uggv\'enynek olyan esetekben, hogy \'eppen null\'ara sk\'al\'azta a Knative rendszer a podj\'at, vagy a k\'er\'es be\'erkez\'esekor m\'ar l\'etezett a Podja. Erre az esetre olyan m\'er\'est alak\'itottam ki, amely elk\"uld egy k\'er\'est a f\"uggv\'eny fele, egy \'allom\'anyba r\"oggz\'iti a v\'alaszidőt, majd k\"ozvetlen ez ut\'an ism\'etelten k\'er\'est k\"uld \'es egy m\'asik \'allom\'anyba r\"ogz\'iti ezt a v\'alaszidőt. Ez ut\'an az \'altalam k\'esz\'itett szkript v\'ar pontosan k\'et percet. Az\'ert ennyi időt, mert tapasztalataim alapj\'an k\"or\"ulbel\"ul m\'asf\'el percig tartott a f\"uggv\'enyek Podjainak termin\'al\'asa, a v\'arakoz\'asnak pedig enn\'el nagyobb időt szerettem volna be\'all\'itani arra az esetre, amikor enn\'el is tov\'abb tart a le\'all\'as. A m\'er\'est egy bash szkript seg\'its\'eg\'evel lehet elk\'esz\'iteni, ami addig fut, am\'ig a felhaszn\'al\'o le nem \'all\'itja. Bőv\'iteni egyszerűen lehet, ugyanis a m\'erendő f\"uggv\'enyek egy list\'aban vannak felsorolva, minden v\'arakoz\'as előtt az ott felsorolt f\"uggv\'enyekre megt\"ort\'enik a v\'alaszidők m\'er\'ese.
\section{M\'er\'esi eredm\'enyek automatiz\'alt elemz\'ese} \section{M\'er\'esi eredm\'enyek automatiz\'alt elemz\'ese}
Egy mérés eredményeként a mérés típusától függően akár több, nagy méretű csv állomány keletkezik. Ezen fájlok feldolgozása függ attól, hogy azt a Jmeter vagy a hey generálta. A fájlok kézi feldolgozása nyilvánvalóan lehetetlen. Az is előfordulhat, hogy már korábban feldolgozott méréseket egy új szempontból is fel kell dolgozni. Ez elő is fordult, ugyanis a program első verziója még nem volt képes az észlelt késleltetés feldolgozására. Szerencsére a Python programnyelv ilyen feladatok elvégzésére kiváló választás. Egy mérés eredményeként a mérés típusától függően akár több, nagy méretű csv állomány keletkezik. Ezen fájlok feldolgozása függ attól, hogy azt a Jmeter vagy a hey generálta. A fájlok kézi feldolgozása nyilvánvalóan lehetetlen. Az is előfordulhat, hogy már korábban feldolgozott méréseket egy új szempontból is fel kell dolgozni. Ez elő is fordult, ugyanis a program első verziója még nem volt képes az észlelt késleltetés feldolgozására. Szerencsére a Python programnyelv ilyen feladatok elvégzésére kiváló választás.

8
src/content/results.tex
View File

@ -12,8 +12,6 @@ Az \ref{fig:docker-chart} ábrából látszik, hogy a várakozásokkal ellentét
Az ábráról szintén látszik, hogy a prím számoló függvény teljesítménye alulmarad a kis számításigényű függvényhez képest. Ez az előzetes várakozások szerint alakult. Mivel a Kubeless egy teljes Function as a Service rendszer, az oda telep\'it\'esre sz\'ant f\"uggv\'enyeket csak a rendszerbe telep\'itve lehet futtatni. Az ábráról szintén látszik, hogy a prím számoló függvény teljesítménye alulmarad a kis számításigényű függvényhez képest. Ez az előzetes várakozások szerint alakult. Mivel a Kubeless egy teljes Function as a Service rendszer, az oda telep\'it\'esre sz\'ant f\"uggv\'enyeket csak a rendszerbe telep\'itve lehet futtatni.
%TODO Coldstart
Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb. Igaz, hogy ez esetben nincs szükség a mérést fél perces szegmensekre bontani. Különösen furcsa a hey viselkedése, ugyanis a hiszterézis akkor nem volt megfigyelhető, ha a függvényt közvetlen Dockerben futtattam. Emiatt használatát nem vetettem el, de az általa mért feldolgozott kérési rátát fenntartással kezeltem. Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb. Igaz, hogy ez esetben nincs szükség a mérést fél perces szegmensekre bontani. Különösen furcsa a hey viselkedése, ugyanis a hiszterézis akkor nem volt megfigyelhető, ha a függvényt közvetlen Dockerben futtattam. Emiatt használatát nem vetettem el, de az általa mért feldolgozott kérési rátát fenntartással kezeltem.
Az \ref{fig:jmeter-for-otodik-chart} \'es \aref{fig:knative-for-negyedik-chart} ábrákon látható a Knative-ba telepített echo típusú függvény skálázódása. A kettő közül először az alsó mérést végeztem el, ahol a hey instabil viselkedése szintén megfigyelhető. A mérés körülbelül felénél látható megemelkedett ráta konzisztensen megismételhető volt több, független Kubernetes klaszteren is. Az ábrák elején jól megfigyelhető a Knative pánik skálázása, amely gyorsan létrehoz öt Podot, majd a hatvan másodperces panic windows lejárta után a már nem szükséges podokat leállítja. Az ezután a Podok számában megfigyelhető hiszterézis a Jmeteres ábrán és egyéb Jmeteres mérések során nem volt tapasztalható. Ez betudható annak, hogy az ObservedStableConcurrency érték a döntési határértéken van. Szintén megfigyelhető, hogy a Podok kiszámításának korábban ismertetett formulája úgy tűnik nem volt helyes. Ez nem helyes következtetés, ugyanis a hey ábrán látható három, valamint a Jmeter ábrán látható kettő kiszámított Podszámhoz hozzáadódik az egy mindig létező Pod. Az ObservedStableConcurrency érték esése a Jmeter ábra esetén is látható, amire a Podok számának csökkentésével reagál a rendszer. Érdekes, hogy itt mind a Podok száma, mint az ObservedStableConcurrency sokkal stabilabbak, cserébe alacsonyabbak. Szintén különbség, hogy a hey esetében a mérés elején tapasztalható alacsony teljesítményű időszak időben hasonló, viszont nincs benne ugrás. Mindkét ábrán látszik, hogy az ObservedStableConcurrency érték mozgó átlag, emiatt lassan változik. Ennek következménye, hogy a terhelés megszűnése után nem szűnnek meg a létrehozott Podok. Az \ref{fig:jmeter-for-otodik-chart} \'es \aref{fig:knative-for-negyedik-chart} ábrákon látható a Knative-ba telepített echo típusú függvény skálázódása. A kettő közül először az alsó mérést végeztem el, ahol a hey instabil viselkedése szintén megfigyelhető. A mérés körülbelül felénél látható megemelkedett ráta konzisztensen megismételhető volt több, független Kubernetes klaszteren is. Az ábrák elején jól megfigyelhető a Knative pánik skálázása, amely gyorsan létrehoz öt Podot, majd a hatvan másodperces panic windows lejárta után a már nem szükséges podokat leállítja. Az ezután a Podok számában megfigyelhető hiszterézis a Jmeteres ábrán és egyéb Jmeteres mérések során nem volt tapasztalható. Ez betudható annak, hogy az ObservedStableConcurrency érték a döntési határértéken van. Szintén megfigyelhető, hogy a Podok kiszámításának korábban ismertetett formulája úgy tűnik nem volt helyes. Ez nem helyes következtetés, ugyanis a hey ábrán látható három, valamint a Jmeter ábrán látható kettő kiszámított Podszámhoz hozzáadódik az egy mindig létező Pod. Az ObservedStableConcurrency érték esése a Jmeter ábra esetén is látható, amire a Podok számának csökkentésével reagál a rendszer. Érdekes, hogy itt mind a Podok száma, mint az ObservedStableConcurrency sokkal stabilabbak, cserébe alacsonyabbak. Szintén különbség, hogy a hey esetében a mérés elején tapasztalható alacsony teljesítményű időszak időben hasonló, viszont nincs benne ugrás. Mindkét ábrán látszik, hogy az ObservedStableConcurrency érték mozgó átlag, emiatt lassan változik. Ennek következménye, hogy a terhelés megszűnése után nem szűnnek meg a létrehozott Podok.
@ -50,6 +48,12 @@ Az \ref{fig:hatodik-isprime-knative-for-chart} \'es \aref{fig:jmeter-hatodik-py-
\label{fig:jmeter-hatodik-py-chart} \label{fig:jmeter-hatodik-py-chart}
\end{figure} \end{figure}
%TODO Coldstart
Ez ut\'an m\'ertem ki, mennyi a k\"ul\"onbs\'eg a f\"uggv\'eny v\'alaszidej\'eben az esetben, hogy null\'ara van sk\'al\'azva, vagy sem. A tapasztalat az volt, hogy 2-3 m\'asodpercig tart a Pod l\'etrehoz\'asa, a v\'alaszidő ennyivel n\"ovekedett meg az echo t\'ipus\'u f\"uggv\'eny eset\'eben. A bevezetett, nagyobb sz\'am\'it\'asig\'enyű f\"uggv\'eny e m\'er\'es sor\'an hasonl\'oan viselkedett. Ez az\'ert \'erdekes, mert a k\'et f\"uggv\'eny m\'asik futtat\'ok\"ornyezettel rendelkezik, tipikusan a Python interpreter elind\'it\'asa 1-2 m\'asodpercet vesz ig\'enybe, arra sz\'am\'itottam, a pr\'imsz\'amol\'o f\"uggv\'eny null\'ara sk\'al\'az\'as eset\'eben ennyivel hosszabb idő alatt fog v\'alaszolni.
Az \ref{fig:hello-coldvhot} \'abr\'an l\'athat\'o az echo t\'ipus\'u f\"uggv\'eny v\'alaszidej\'enek alakul\'asa. A m\'er\'est k\"or\"ulbel\"ul tizenk\'et \'or\'aig futtattam.%TODO
<hello-coldvhot>
<isprime-coldvhot>
Az \ref{fig:hatodik-hello-knative-climb-chart} ábrán látható az echo típusú függvényre egyre növekvő terhelés, valamint a Knative Autoscaler rendszer e mérés alatti belső állapota. A terhelés növelését a hey mérőeszközben egyre több connection objektum használta által értem el. Jól látszik, hogy az ObservedStableConcurrency egy lassan változó érték, a mérés végére töredékét érte el annak az értéknek, amit az egyenletes terhelésű mérések során elért. Szintén látható a Podok számából, hogy pánik állapotot sem váltott ki a mérés. Erre nem is lehetett számítani, hiszen a használt konkurencia érték sosem növekedett duplájára hat másodperces időtartam alatt. Az \ref{fig:hatodik-hello-knative-climb-chart} ábrán látható az echo típusú függvényre egyre növekvő terhelés, valamint a Knative Autoscaler rendszer e mérés alatti belső állapota. A terhelés növelését a hey mérőeszközben egyre több connection objektum használta által értem el. Jól látszik, hogy az ObservedStableConcurrency egy lassan változó érték, a mérés végére töredékét érte el annak az értéknek, amit az egyenletes terhelésű mérések során elért. Szintén látható a Podok számából, hogy pánik állapotot sem váltott ki a mérés. Erre nem is lehetett számítani, hiszen a használt konkurencia érték sosem növekedett duplájára hat másodperces időtartam alatt.
\begin{figure}[!ht] \begin{figure}[!ht]