From 700cc4970cbbffdd6e246a1554ce76983357a961 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torma=20Krist=C3=B3f?= Date: Sat, 7 Dec 2019 00:23:14 +0100 Subject: [PATCH] =?UTF-8?q?text=20about=20coldstart=20m=C3=A9r=C3=A9s?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/content/preparation.tex | 3 +++ src/content/results.tex | 8 ++++++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/content/preparation.tex b/src/content/preparation.tex index e5ba2c0..b96029f 100644 --- a/src/content/preparation.tex +++ b/src/content/preparation.tex @@ -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. +\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} 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. diff --git a/src/content/results.tex b/src/content/results.tex index c5f4a2c..301a4d9 100644 --- a/src/content/results.tex +++ b/src/content/results.tex @@ -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. -%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. 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} \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 + + + 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]