minor modifications

src/content/results.tex

@@ -1,4 +1,7 @@
 \chapter{M\'er\'esi eredm\'enyek ismertet\'ese}
+
+\section{Elk\'esz\'itett f\"uggv\'enyek teljes\'itm\'eny\'enek m\'er\'ese Dockerben telep\'itve}
+
 Mielőtt elkezdtem a Knative és Kubeless rendszerek mérését, annak érdekében, hogy a mérőeszközök, illetve a Knative-hoz készített függvények teljesítményét kimérjem, mindkét mérőeszközzel megmértem mindkét függvényt Docker konténerként indítva. Itt a függvények a harmadik, a Kubernetes klaszterbe be nem csatlakoztatott számítógépen futottak a függvények, a mérések pedig az Kubernetes Masteren futottak. Mind a négy mérés esetében a használt connection objektumok száma negyvenöt. 
 
 Az \ref{fig:docker-chart} ábrából látszik, hogy a várakozásokkal ellentétben a Jmeter jobban teljesített, mint a hey. Ez azért van, mert a hey-re megszabtam connection objektumomként ötszáz kérés per másodperces korlátot. Erre a számra úgy jutottam, hogy a hey által használt connection objektumok számát egyre állítottam. Ez esetben a generált kérések száma másodpercenként 510 és 530 között ingadozott, viszont stabilan mindig 500 felett volt. A generált forgalom stabilizálása érdekében az 500-nál húztam meg a határt, melynek szükségességét a korábbi tapasztalatok alapján éreztem, ugyanis a hey teljesítménye megfigyeléseim szerint instabil, mikor nagy sebességgel kell generálja a kéréseket. Továbbá, úgy ítéltem, hogy két különbözően viselkedő mérőeszköz többet fed fel a skálázódási mechanizmusokról. 
@@ -14,6 +17,8 @@ Az ábráról szintén látszik, hogy a prím számoló függvény teljesítmén
 
 É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. 
 
+\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 ö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. 
 
 \begin{figure}[!ht]
@@ -48,6 +53,8 @@ Az \ref{fig:hatodik-isprime-knative-for-chart} \'es \aref{fig:jmeter-hatodik-py-
 \label{fig:jmeter-hatodik-py-chart}
 \end{figure}
 
+\section{F\"uggv\'enyek v\'alaszidej\'enek alakul\'asa cold \'es hotstart esetekben}
+
 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, viszont \'atlagosan egy m\'asodperccel tov\'abb tartott a Pod indul\'asa. 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, ez megmagyar\'azza, mi\'ert tapasztalhat\'o ez a k\"ul\"onbs\'eg - amely j\'ol megfigyelhető \aref{fig:go-start-chart} \'es \aref{fig:py-start-chart} \'abr\'akon - a k\'et f\"uggv\'eny k\"oz\"ott.
 
 Az \ref{fig:go-start-chart} \'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. Ezen \'es \aref{fig:py-start-chart} \'abr\'an megfigyelhető, hogy a v\'alaszidő Hotstart, azaz l\'etező Pod eset\'eben sokkal stabilabb, mint Coldstart, azaz nem l\'etező Pod eset\'eben.
@@ -67,6 +74,8 @@ Az \ref{fig:go-start-chart} \'abr\'an l\'athat\'o az echo t\'ipus\'u f\"uggv\'en
 \label{fig:py-start-chart}
 \end{figure}
 
+\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á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]
@@ -85,6 +94,8 @@ A korábbi mérések alapján számítottam rá, hogy a prímszámoló függvén
 \label{fig:hatodik-isprime-knative-climb-chart}
 \end{figure}
 
+\section{Istio \'es Nginx Ingress Controllerek \"osszehasonl\'it\'asa}
+
 Mivel a Knative és Kubeless rendszerek másik Ingress Controllert használtak, szerettem volna kimérni ezek áteresztőképességét is. Ezt úgy vittem véghez, hogy a mérőeszközzel mindkét Ingress Controller végpontját megcéloztam, mint ahogyan azt a függvények teljesítményének mérésénél is tettem, viszont ez esetben általuk nem ismert hosztnév fejlécet adtam meg. Ez által minden kérésre 404-es http kóddal válaszoltak. Az \ref{fig:istio-nginx-chart} ábrákon látható teljesítmény az adott Ingress Controllerek által elérhető legjobb teljesítmény. A Kubeless által használt Nginx Ingress Controller teljesítménye majdnem négyszeresen meghaladja a Knative által használt Isitio. 
 
 \begin{figure}[!ht]
@@ -94,6 +105,8 @@ Mivel a Knative és Kubeless rendszerek másik Ingress Controllert használtak,
 \label{fig:istio-nginx-chart}
 \end{figure}
 
+\section{Kubeless rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa}
+
 Ahogy \aref{fig:kubeless-isprime} ábrán látszik, a Kubeless skálázódása teljesen máshogy működik. Ez esetben a kötelezően meghatározott cpu használati limit miatt a skálázódáson a teljesítményben is érzékelhető a több Pod használata. Szintén látszik, hogy a csúcsteljesítmény, amit elért magasabb, mint a Knative esetében. Cserébe, viszont a skálázódás lassabb, a Horizontal Pod Autoscaler hatvan másodperces átlagolása miatt. 
 
 \begin{figure}[!ht]
@@ -125,6 +138,8 @@ Korábbi mérések során a prímszámoló függvény egy Python folyamatot hasz
 \label{fig:jmeter-pillanat-junky-chart}
 \end{figure}
 
+\section{Knative belső \'allapotainak vizsg\'alata monitoring rendszerekkel}
+
 Kíváncsi voltam, egyes mérések során milyen belső állapotai vannak a Knative egyes alegységeinek. Azért, hogy ezeket megfigyelhessem, telepítettem a Knative Monitoring egységét. Ez után újra elvégeztem bizonyos méréseket. Először a prímszámoló függvény viselkedését vizsgáltam meg. Érdekes, hogy a Workeren elérhető húsz magból összesen hetet sem használnak.
 
 Az \ref{fig:grafana-isprime-controllvsdata} ábrán látható, hogy a függvényt kiszolgáló Podok és a Knative rendszer processzorhasználata hogyan alakul egymáshoz képest.  Érdekes, hogy együtt is csupán körülbelül tíz processzormagot használnak. A Control Plane az ábrán a Knative Serving egyes komponenseit, az Istio-t, a monitoring eszközöket és a Kubernetes beépített részeit jelenti. A lenti ábrán látható ezen komponensek között miként oszlik el a processzorhasználat.