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

oscc

Browse Source
This commit is contained in:
Torma Kristóf 2019-12-12 18:55:39 +01:00
parent 33779d99ee
commit 50f033163a
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/content/results.tex
View File

@ -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} \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] \begin{figure}[!ht]
\centering \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. 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] \begin{figure}[!ht]
\centering \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} \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] \begin{figure}[!ht]
\centering \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} \label{fig:hatodik-hello-knative-climb-chart}
\end{figure} \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] \begin{figure}[!ht]
\centering \centering