From 50f033163a3b5fda5905343add47f47e61f00d86 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torma=20Krist=C3=B3f?= Date: Thu, 12 Dec 2019 18:55:39 +0100 Subject: [PATCH] oscc --- src/content/results.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/results.tex b/src/content/results.tex index a5f8ab7..b043f22 100644 --- a/src/content/results.tex +++ b/src/content/results.tex @@ -19,7 +19,7 @@ Az ábráról szintén látszik, hogy a prímszámoló függvény teljesítmény \section{Knative rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa egyenletes terhel\'es alatt} -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 5 podot, majd a 60 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 viszont 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 \aref{fig:jmeter-for-otodik-chart} á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 \aref{fig:jmeter-for-otodik-chart} á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 5 podot, majd a 60 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 viszont nem volt tapasztalható. Ez betudható annak, hogy az \textit{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 \aref{fig:jmeter-for-otodik-chart} ábrán látható kettő kiszámított podszámhoz hozzáadódik az egy mindig létező pod. Az \textit{ObservedStableConcurrency} érték esése \aref{fig:jmeter-for-otodik-chart} á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 \textit{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 \textit{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. \begin{figure}[!ht] \centering @@ -37,7 +37,7 @@ Az \ref{fig:jmeter-for-otodik-chart} \'es \aref{fig:knative-for-negyedik-chart} A mérések alapján kíváncsi voltam, mi történik, ha alacsonyabb áteresztőképességű függvényre generált terhelés esetében vizsgálom meg a Knative belső működését. -Az \ref{fig:hatodik-isprime-knative-for-chart} \'es \aref{fig:jmeter-hatodik-py-chart} ábrákon látható függvény teljesítményének karakterisztikája teljesen más, mint az echo típusú függvényé. Olyan szempontból hasonlítanak, hogy kell idő mindkét függvénynek, hogy a teljesítménye elérje a stabil értéket, viszont ellentétben az echo típusú függvénnyel, ezt nem egyik másodpercről a másikra teszi a prímszámoló függvény, hanem folyamatosan. Az ObservedStableConcurrency viszont a várakozásoknak nem megfelelően alakult. Intuíció alapján azt vártam el, hogy hasonló terhelés és kisebb áteresztő képesség miatt ez az érték megemelkedik, aminek következtében aztán a podok száma is megnő. Ennek viszont az ellenkezője történt. Az alacsonyabb áteresztő képesség ellenére az ObservedStableConcurrency is alacsonyabb volt, így a podok száma is alacsonyabb maradt. Ez betudható annak, hogy amíg a függvény vissza nem tér, foglalja az adott connection objektumot, amely meghívta. +Az \ref{fig:hatodik-isprime-knative-for-chart} \'es \aref{fig:jmeter-hatodik-py-chart} ábrákon látható függvény teljesítményének karakterisztikája teljesen más, mint az echo típusú függvényé. Olyan szempontból hasonlítanak, hogy kell idő mindkét függvénynek, hogy a teljesítménye elérje a stabil értéket, viszont ellentétben az echo típusú függvénnyel, ezt nem egyik másodpercről a másikra teszi a prímszámoló függvény, hanem folyamatosan. Az \textit{ObservedStableConcurrency} viszont a várakozásoknak nem megfelelően alakult. Intuíció alapján azt vártam el, hogy hasonló terhelés és kisebb áteresztő képesség miatt ez az érték megemelkedik, aminek következtében aztán a podok száma is megnő. Ennek viszont az ellenkezője történt. Az alacsonyabb áteresztő képesség ellenére az \textit{ObservedStableConcurrency} is alacsonyabb volt, így a podok száma is alacsonyabb maradt. Ez betudható annak, hogy amíg a függvény vissza nem tér, foglalja az adott connection objektumot, amely meghívta. \begin{figure}[!ht] \centering @@ -76,7 +76,7 @@ Az \ref{fig:go-start-chart} \'abr\'an l\'athat\'o az echo t\'ipus\'u f\"uggv\'en \section{Knative rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa n\"ovekedő terhel\'es 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álata á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 6 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álata által értem el. Jól látszik, hogy az \textit{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 6 másodperces időtartam alatt. \begin{figure}[!ht] \centering @@ -85,7 +85,7 @@ Az \ref{fig:hatodik-hello-knative-climb-chart} ábrán látható az echo típus \label{fig:hatodik-hello-knative-climb-chart} \end{figure} -A korábbi mérések alapján számítottam rá, hogy a prímszámoló függvény újból máshogy fog viselkedni. Nem csal\'odtam, ugyanis ez\'uttal az ObservedStableConcurrency \'ert\'ek gyorsabban n\"ovekedett, mint a terhel\'es, viszont a f\"uggv\'eny teljes\'itm\'enye nehezebben alkalmazkodott a terhel\'eshez. Az is megfigyelhető \aref{fig:hatodik-isprime-knative-climb-chart} \'abr\'an, hogy ez esetben nem j\"ott l\'etre m\'asodik pod. +A korábbi mérések alapján számítottam rá, hogy a prímszámoló függvény újból máshogy fog viselkedni. Nem csal\'odtam, ugyanis ez\'uttal az \textit{ObservedStableConcurrency} \'ert\'ek gyorsabban n\"ovekedett, mint a terhel\'es, viszont a f\"uggv\'eny teljes\'itm\'enye nehezebben alkalmazkodott a terhel\'eshez. Az is megfigyelhető \aref{fig:hatodik-isprime-knative-climb-chart} \'abr\'an, hogy ez esetben nem j\"ott l\'etre m\'asodik pod. \begin{figure}[!ht] \centering