diff --git a/src/.kile/thesis.kilepr.gui b/src/.kile/thesis.kilepr.gui
index 2cd60a6..400a320 100644
--- a/src/.kile/thesis.kilepr.gui
+++ b/src/.kile/thesis.kilepr.gui
@@ -2,7 +2,7 @@
 kile_livePreviewEnabled=true
 kile_livePreviewStatusUserSpecified=true
 kile_livePreviewTool=LivePreview-XeLaTeX
-lastDocument=content/introduction.tex
+lastDocument=content/theory.tex
 
 [document-settings,item:../../thesis-template-latex/src/thesis.tex]
 Bookmarks=
@@ -160,12 +160,12 @@ TextFolding=[]
 ViMarks=
 
 [view-settings,view=0,item:content/abstract.tex]
-CursorColumn=27
-CursorLine=14
-Dynamic Word Wrap=false
+CursorColumn=113
+CursorLine=35
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,14,26,[,14,23,],14,26
+ViMarks=.,16,265,[,16,264,],16,265
 
 [view-settings,view=0,item:content/acknowledgement.tex]
 CursorColumn=0
@@ -184,57 +184,57 @@ TextFolding=[]
 ViMarks=.,181,0,[,181,0,],181,9
 
 [view-settings,view=0,item:content/closing.tex]
-CursorColumn=253
-CursorLine=14
-Dynamic Word Wrap=false
+CursorColumn=319
+CursorLine=9
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,14,253,[,14,253,],14,253
+ViMarks=.,9,284,[,9,284,],9,284
 
 [view-settings,view=0,item:content/create-functions.tex]
-CursorColumn=57
-CursorLine=3
-Dynamic Word Wrap=false
+CursorColumn=740
+CursorLine=57
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,3,171,[,3,167,],3,171
+ViMarks=.,57,517,[,57,517,],57,517
 
 [view-settings,view=0,item:content/introduction.tex]
-CursorColumn=488
-CursorLine=9
-Dynamic Word Wrap=false
+CursorColumn=64
+CursorLine=11
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,9,481,[,9,481,],9,481
+ViMarks=.,11,274,[,11,274,],11,274
 
 [view-settings,view=0,item:content/preparation.tex]
-CursorColumn=61
-CursorLine=134
-Dynamic Word Wrap=false
+CursorColumn=183
+CursorLine=42
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,123,551,[,123,542,],123,551
+ViMarks=.,42,182,[,42,182,],42,182
 
 [view-settings,view=0,item:content/results.tex]
-CursorColumn=575
-CursorLine=118
-Dynamic Word Wrap=false
+CursorColumn=286
+CursorLine=4
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,118,574,[,118,554,],118,574
+ViMarks=.,144,168,[,144,168,],144,168
 
 [view-settings,view=0,item:content/theory.tex]
 CursorColumn=0
-CursorLine=38
-Dynamic Word Wrap=false
+CursorLine=188
+Dynamic Word Wrap=true
 JumpList=
 TextFolding=[]
-ViMarks=.,115,78,[,116,0,],116,26
+ViMarks=.,189,111,[,189,111,],189,111
 
 [view-settings,view=0,item:thesis.tex]
-CursorColumn=29
-CursorLine=74
+CursorColumn=40
+CursorLine=12
 Dynamic Word Wrap=false
 JumpList=
 TextFolding=[]
-ViMarks=.,102,0,[,102,0,],102,0
+ViMarks=.,12,39,[,12,39,],12,39
diff --git a/src/content/closing.tex b/src/content/closing.tex
index 68a8acf..837aa05 100644
--- a/src/content/closing.tex
+++ b/src/content/closing.tex
@@ -2,14 +2,14 @@
 \chapter{\"Osszefoglal\'as}
 
 \section{K\"ovetkeztet\'esek}
-A méréseim alapján számos következtetést le lehet vonni a Knative és a Kubeless skálázási mechanizmusairól. Tisztán látható, hogy a pánik skálázásnak hála a Knative gyorsan képes reagálni a hirtelen érkező nagy terhelésre. Ennek gyakorlati haszna egy új szolgáltatás bevezetésnél lehet, ugyanis ilyen esetekben rövid idő alatt kell lefoglalni a szükséges erőforrásokat. Az is megfigyelhető, hogy a stabil, vagy lassan változó terhelésre nehézkesen változik. Ez az ObservedStableConcurrency belső érték mozgó átlag jellegéből adódik. Például, ezen érték csökkenését kiváltó esemény akár fél perccel korábban is lehetett. Továbbá, például egy szolgáltatás inkrementális bevezetése esetén érkező, lassan, de folyamatosan növekvő terhelés esetén előfordulhat, hogy később hozza létre a szükséges Podokat a Knative, mint kéne. 
+A méréseim alapján számos következtetést le lehet vonni a Knative és a Kubeless skálázási mechanizmusairól. Tisztán látható, hogy a pánik skálázásnak hála a Knative gyorsan képes reagálni a hirtelen érkező nagy terhelésre. Ennek gyakorlati haszna egy új szolgáltatás bevezetésnél lehet, ugyanis ilyen esetekben rövid idő alatt kell lefoglalni a szükséges erőforrásokat. Az is megfigyelhető, hogy a stabil, vagy lassan változó terhelésre nehézkesen változik. Ez az ObservedStableConcurrency belső érték mozgó átlag jellegéből adódik. Például, ezen érték csökkenését kiváltó esemény akár fél perccel korábban is lehetett. Továbbá, például egy szolgáltatás inkrementális bevezetése esetén érkező, lassan, de folyamatosan növekvő terhelés esetén előfordulhat, hogy később hozza létre a szükséges podokat a Knative, mint kéne.
 
 A Kubeless a Knative-val szemben sokkal egyszerűbb skálázási mechanizmust alkalmaz. Nem számít, hogy a terhelés milyen karakterisztikával éri el a skálázási határt, ha a processzor használat meghaladja az előre beállított értéket, felskálázza a függvényt. Eme egyszerűség hátránya, hogy nem képes gyorsan reagálni a rövid idő alatt megnövekedő terhelésre. Fontosnak tartom megemlíteni, hogy annak ellenére, hogy ez az egyszerűbb rendszer, a Knative esetében nem ütköztem olyan hibába, amely meggátolta volna a rendszer használatát.
 
 \section{Tov\'abbi kutat\'asi lehetős\'egek}
-Az általam elvégzett munka számos irányba folytatható. Érdekes lehet ugyanezen méréseket elvégezni olyan klaszteren, amelynek több Worker is tagja. Ez \'altal a Workerek k\"oz\"otti \"utemez\'es elem\'ez\'es\'ere is lehetős\'eg ny\'ilik. Emellett \'erdemes lehet menedzselt Kubernetes-be - p\'eld\'aul Google Kubernetes Engine-be - telep\'itett Knative viselked\'es\'enek vizsg\'alata.
+Az általam elvégzett munka számos irányban folytatható. Érdekes lehet ugyanezen méréseket elvégezni olyan klaszteren, amelynek több Worker is tagja. Ez \'altal a Workerek k\"oz\"otti \"utemez\'es elem\'ez\'es\'ere is lehetős\'eg ny\'ilik. Emellett \'erdemes lehet menedzselt Kubernetes-be - p\'eld\'aul Google Kubernetes Engine-be - telep\'itett Knative viselked\'es\'enek vizsg\'alata.
 
-Az elkészített Python programok és bash szkriptek felhasználhatók akár a Knative további mérései során, vagy kisebb adaptációkkal könnyen felhasználható másik rendszerek mérésére. Hasonlóan, az eszközkészlet továbbfejlesztése, komplexebb ábrák, azok finomítása hasznos és érdekes további fejlesztési irány lehet.
+Az elkészített Python programok és Bash szkriptek felhasználhatók akár a Knative további mérései során vagy kisebb adaptációkkal könnyen felhasználható más rendszerek mérésére. Hasonlóan, az eszközkészlet továbbfejlesztése, komplexebb ábrák, azok finomítása hasznos és érdekes további fejlesztési irány lehet.
 
 \section{Tapasztalataim}
-Számomra kifejezetten érdekes és hasznos volt a féléves munka. Nem csak egy új rendszerről tanultam sokat, de megtanultam, hogy érdemes automatizálni egy komplex munkafolyamatot. Én a továbbiakban legszívesebben ebbe az irányba dolgoznék a továbbiakban.
+Számomra kifejezetten érdekes és hasznos volt a féléves munka. Nem csak egy új rendszerről tanultam sokat, de megtanultam, hogyan érdemes automatizálni egy komplex munkafolyamatot. Én a továbbiakban legszívesebben ebben az irányban dolgoznék a továbbiakban.
diff --git a/src/content/create-functions.tex b/src/content/create-functions.tex
index 7043da2..952bb4f 100644
--- a/src/content/create-functions.tex
+++ b/src/content/create-functions.tex
@@ -1,9 +1,9 @@
 \chapter{F\"uggv\'enyek l\'etrehoz\'asa}
 A rendszerek sajátosságai miatt ugyanazt a kódot nem lehet változtatás nélkül felhasználni a két eltérő rendszerben. Mindkét rendszerre két tesztfüggvényt valósítottam meg. Az egyik célja a lehető legrövidebb válaszidő és a legnagyobb áteresztőképesség. A másik célja a kérésenként nagyobb processzorterhelés generálása. 
 
-Az első egy Go nyelven megvalósított tesztfüggvény, amely a meghívás után “Hello Go!” szöveggel tér vissza. A Kubeless rendszerhez írt függvény szignatúrája egyezik a \aref{code:hello-kubeless-go} k\'odr\'eszletben l\'athat\'o függvényével. Függőségként importálni kell a Kubeless sztenderd könyvtárát.
+Az első egy Go nyelven megvalósított tesztfüggvény, amely a meghívás után “Hello Go!” szöveggel tér vissza. A Kubeless rendszerhez írt függvény szignatúrája egyezik \aref{code:hello-kubeless-go} k\'odr\'eszletben l\'athat\'o függvényével. Függőségként importálni kell a Kubeless sztenderd könyvtárát.
 
-Knative rendszerben szükség van a Go sztenderd könyvtárban megtalálható HTTP szerver implementációra, valamint egy belépési függvényre, amely elindítja a webszervert és beköti a függvényünket úgy, hogy az alapértelmezett URL, ahol elindul a webszerver, az ide érkező kéréseket továbbítsa neki. Mivel a Knative-ba Docker Image-eket lehet telepíteni, ezért azt is létre kell hozni. Annak érdekében, hogy a végső Image a lehető legkisebb méretű legyen, a Go program binárissá fordítását külön végezzük el, a végső Image-be csak bemásoljuk azt. Erre a Docker ad eszközt, az úgynevezett multi-stage buildek segítségével. Ez azt jelenti, hogy egy külön végrehajtási láncot leírva lefordítjuk a kódot, majd a végső Image-be csak bemásoljuk a fordítással végzett konténer Image-éből. Az elkészült Image-et - melyet le\'ir\'o Docker file \aref{code:dockerfile-hello-go} k\'odr\'eszleten l\'athat\'o - a Docker Hubra feltöltöttem, hogy ne kelljen minden frissen telepített Workernek megépítenie az Image-et.
+Knative rendszerben szükség van a Go sztenderd könyvtárban megtalálható HTTP szerver implementációra, valamint egy belépési függvényre, amely elindítja a webszervert és beköti a függvényünket úgy, hogy az alapértelmezett URL - ahol elindul a webszerver, az ide érkező kéréseket továbbítsa neki. Mivel a Knative-ba Docker Image-eket lehet telepíteni, ezért azt is létre kell hozni. Annak érdekében, hogy a végső Image a lehető legkisebb méretű legyen, a Go program binárissá fordítását külön végezzük el, a végső Image-be csak bemásoljuk azt. Erre a Docker ad eszközt, az úgynevezett multi-stage buildek segítségével. Ez azt jelenti, hogy egy külön végrehajtási láncot leírva lefordítjuk a kódot, majd a végső Image-be csak bemásoljuk a fordítással végzett konténer Image-éből. Az elkészült Image-et - melyet le\'ir\'o Dockerfile \aref{code:dockerfile-hello-go} k\'odr\'eszleten l\'athat\'o - a Docker Hubra feltöltöttem, hogy ne kelljen minden frissen telepített Workernek megépítenie az Image-et.
 
 \begin{lstlisting}[float=!ht,caption={Echo t\'ipus\'u f\"uggv\'eny Docker Image-\'et le\'ir\'o Dockerfile},label=code:dockerfile-hello-go]
 FROM golang:1.13 as builder
@@ -30,9 +30,9 @@ A várhatóan nagyobb processzorterhelést generáló függvényként egy Python
 
 A Knative esetében szintén eltérő módon érdemes Docker Image-et készíteni a megírt függvényből. Szükség van a Flask nevű könyvtárra, amely segítségével webes alkalmazásokat lehet készíteni Pythonban. Használata igen hasonló a Go-ban megtalálható implementációhoz. Úgynevezett dekorátor segítségével lehet a Flask számára jelezni, hogy az adott függvény milyen URL meghívásakor fusson le, valamint a használni kívánt port számát is itt lehet megadni. A Docker Image építése során multi-stage build használatára nincsen szükség, hiszen a Python értelmezőnek mindenképpen jelen kell lennie a végső Image-ben is. A Flask telepítése mellett úgy döntöttem, hogy a gunicorn Pythonban implementált webszervert is telepítem, valamint azt használom, mint webszervert a Docker Image-ben. Használatának előnye, hogy képes kihasználni a Python által nyújtott multiprocessing lehetőségeket, amely azt jelenti, hogy több Python értelmezőt indítva, több folyamat használatával jobb teljesítményt lehet elérni, mint több szál használatával, ugyanis a Python értelmező egyszerre egy szálon futó programkódot értelmez. 
 
-Minden Knative függvényhez definiáltam egy-egy YAML állományban egy olyan Service-t, amelyhez tartozó Podok számát nullára képes leskálázni a rendszer, valamint egy konkurencia alapú skálázást használó Service-t. Az ut\'obbit le\'ir\'o YAML \'allom\'any \aref{code:yaml-isprime-py} k\'odr\'eszleten l\'athat\'o. 
+Minden Knative függvényhez definiáltam egy-egy YAML állományban egy olyan Service-t, amelyhez tartozó podok számát nullára képes leskálázni a rendszer, valamint egy konkurencia alapú skálázást használó Service-t. Az ut\'obbit le\'ir\'o YAML \'allom\'any \aref{code:yaml-isprime-py} k\'odr\'eszleten l\'athat\'o. 
 
-\begin{lstlisting}[float=!ht,caption={P\'irm\'asz\'aml\'al\'o f\"uggv\'eny Knative Service obejktum\'at le\'ir\'o YAML},label=code:yaml-isprime-py]
+\begin{lstlisting}[float=!ht,caption={P\'irmsz\'aml\'al\'o f\"uggv\'eny Knative Service obejktum\'at le\'ir\'o YAML},label=code:yaml-isprime-py]
 apiVersion: serving.knative.dev/v1alpha1
 kind: Service
 metadata:
@@ -55,6 +55,6 @@ spec:
               value: "Py"
 \end{lstlisting}
 
-Az elkészített függvényen, valamint a Docker Image-eket leíró Dockerfile-okat Git verziókezelőrendszerrel kezeltem, a létrehozott repository-t a GitHub szolgáltatásba feltöltöttem. Ez lehetővé tette a Travis Continuos Integration/Continuos Delivery rendszer használatát. Ezt arra használtam, hogy a változások nyugtázása után, valamint azok GitHubra történő feltöltése után a Docker Image-ek automatikusan épüljenek meg, valamint kerüljenek fel a Docker Hubra. Fontos, hogy ez nem feltétlen jelenti, hogy a Kubernetes-ben éppen futó, vagy később létrejövő Podok a legfrissebb Image-et fogják használni. Ahhoz szükség van vagy a latest nevű címkét használni, vagy az ImagePullPolicy nevű opciót bekapcsolni a Knative Service, vagy Kubernetes Deployment definiálásánál. 
+Az elkészített függvényen, valamint a Docker Image-eket leíró Dockerfile-okat Git verziókezelőrendszerrel kezeltem, a létrehozott repository-t a GitHub szolgáltatásba feltöltöttem. Ez lehetővé tette a Travis Continuos Integration/Continuos Delivery rendszer használatát. Ezt arra használtam, hogy a változások nyugtázása után, valamint azok GitHubra történő feltöltése után a Docker Image-ek automatikusan épüljenek meg, valamint kerüljenek fel a Docker Hubra. Fontos, hogy ez nem feltétlen jelenti, hogy a Kubernetes-ben éppen futó vagy később létrejövő podok a legfrissebb Image-et fogják használni. Ehhez szükség van vagy a latest nevű címkét használni vagy az ImagePullPolicy nevű opciót bekapcsolni a Knative Service vagy Kubernetes Deployment definiálásánál. 
 
-Az elkészített függvények Kubelessbe telepítése a korábban telepített parancssori interfész segítségével lehetséges. A függvény telepítése, ahhoz http végpont csatolása, valamint a skálázás létrehozása különálló parancs. Skálázás esetében a processzor limit alkalmazása a függvény telepítését végző parancs argumentumaként adható meg. Ebből adódóan skálázás esetén nem lehet csak a skálázás telepítését végrehajtó parancsot kiadni. A Kubeless függvények telepítését megkönnyítendő, elkészítettem egy bash nyelven írt szkriptet, amely paramétereként elvárja a függvény és az állomány nevét, ami tartalmazza azt, illetve a futtató környezet nevét és azt, hogy kell-e skálázás. Ezek alapján kiadja a szükséges parancsokat helyesen paraméterezve. Ezáltal a parancssori interfész helyes használatát gyorsabbá és könnyebbé tettem. 
+Az elkészített függvények Kubeless-be telepítése a korábban telepített parancssori interfész segítségével lehetséges. A függvény telepítése, ahhoz HTTP végpont csatolása, valamint a skálázás létrehozása különálló parancs. Skálázás esetében a processzor limit alkalmazása a függvény telepítését végző parancs argumentumaként adható meg. Ebből adódóan skálázás esetén nem lehet csak a skálázás telepítését végrehajtó parancsot kiadni. A Kubeless függvények telepítését megkönnyítendő, elkészítettem egy Bash nyelven írt szkriptet, amely paramétereként elvárja a függvény és az állomány nevét, ami tartalmazza azt, illetve a futtató környezet nevét és azt, hogy kell-e skálázás. Ezek alapján kiadja a szükséges parancsokat helyesen paraméterezve. Ezáltal a parancssori interfész helyes használatát gyorsabbá és könnyebbé tettem. 
diff --git a/src/content/preparation.tex b/src/content/preparation.tex
index 7e54d47..ab126be 100644
--- a/src/content/preparation.tex
+++ b/src/content/preparation.tex
@@ -1,7 +1,7 @@
 \chapter{M\'er\'esi k\"ornyezet ismertet\'ese}
 
 \section{Topol\'ogia}
-A mérési infrastruktúra kialakításánál a fő szempont a potenciális szűk keresztmetszetek elkerülése volt, ennek okán a méréseket három nagy teljesítményű szerveren végeztem. A Kubernetes klaszter egy Masterből és egy Workerből állt, a harmadik számítógépen pedig a mérőeszközök futottak. A klaszter fizikai fel\'ep\'it\'ese \aref{fig:phys-cluster} \'abr\'an l\'athat\'o. Az így kialakított mérési klaszter előnye, hogy az egyik gépen futó, nagy erőforrás igényű folyamatok nem vesznek el egy másik gépen futó folyamattól erőforrást. Több Kubernetes Worker használatára volt lehetőség, de mivel egyszerre egy mérés futott, valamint a Workerek közötti elosztást nem volt cél vizsgálni, egyet is elégségesnek ítéltem. 
+A mérési infrastruktúra kialakításánál a fő szempont a potenciális szűk keresztmetszetek elkerülése volt, ennek okán a méréseket három nagy teljesítményű szerveren végeztem. A Kubernetes klaszter egy Masterből és egy Workerből állt, a harmadik számítógépen pedig a mérőeszközök futottak. A klaszter fizikai fel\'ep\'it\'ese \aref{fig:phys-cluster} \'abr\'an l\'athat\'o. Az így kialakított mérési klaszter előnye, hogy az egyik gépen futó, nagy erőforrásigényű folyamatok nem vesznek el egy másik gépen futó folyamattól erőforrást. Több Kubernetes Worker használatára volt lehetőség, de mivel egyszerre egy mérés futott, valamint a Workerek közötti elosztást nem volt cél vizsgálni, egyet is elégségesnek ítéltem. 
 
 \begin{figure}[!ht]
 \centering
@@ -10,81 +10,81 @@ A mérési infrastruktúra kialakításánál a fő szempont a potenciális szű
 \label{fig:phys-cluster}
 \end{figure}
 
-A számítógépek két tíz gigabites hálózati interfészen keresztül is össze vannak kötve. Egyiken keresztül csatlakoznak az internetre, ezen az interfészen publikus IP címmel rendelkeznek. A másikon csak egymást érik el, itt privát IP címük volt. Mindkét interfészen egy Layer 2-es szórási tartományban voltak. Szakdolgozatom elkészítése során több klaszterrel is dolgoztam, melyek fizikailag nem feltétlen voltak egy switchre bekötve, viszont ez legrosszabb esetben is csak minimálisan befolyásolhatja a méréseket.
+A számítógépek két tíz gigabites hálózati interfészen keresztül is össze vannak kötve. Egyiken keresztül csatlakoznak az internetre, ezen az interfészen publikus IP címmel rendelkeznek. A másikon csak egymást érik el, itt privát IP címük volt. Mindkét interfészen egy Layer 2-es szórási tartományban voltak. Szakdolgozatom elkészítése során több klaszterrel is dolgoztam, melyek fizikailag nem feltétlen voltak egy switch-re bekötve, viszont ez legrosszabb esetben is csak minimálisan befolyásolhatja a méréseket.
 
 \section{Mérési környezet automatizált telepítése}
 \subsection{Kubernetes telep\'it\'ese}
-Egy Kubernetes klaszter létrehozásához szükség van egy Master és legalább egy Worker telepítésére. A mérésekhez használt szerverek úgy kerültek telepítésre, hogy a root felhasználó a klaszter bármely másik számítógépét eléri ssh-n a magán hálózaton keresztül, jelszó nélkül. Az automatizmus elkészítéséhez ezt felhasználtam. További megkötés, hogy a telepítő programot a létrehozni kívánt Master-en kell futtatni, a Worker-ek IP címének, vagy hosztnevének listáját pedig egy tömbben kell megadni. A méréseket az Ubuntu operációs 18.04-es verzióján végeztem, ez is fontos megkötés, ugyanis a Linux disztribúciókon elérhető csomagkezelő, valamint egyéb eszközök eltérhetnek. 
+Egy Kubernetes klaszter létrehozásához szükség van egy Master és legalább egy Worker telepítésére. A mérésekhez használt szerverek úgy kerültek telepítésre, hogy a root felhasználó a klaszter bármely másik számítógépét eléri SSH-n a magán hálózaton keresztül, jelszó nélkül. Az automatizmus elkészítéséhez ezt felhasználtam. További megkötés, hogy a telepítő programot a létrehozni kívánt Master-en kell futtatni, a Worker-ek IP címének vagy hosztnevének listáját pedig egy tömbben kell megadni. A méréseket az Ubuntu operációs 18.04-es verzióján végeztem, ez is fontos megkötés, ugyanis a Linux disztribúciókon elérhető csomagkezelő, valamint egyéb eszközök eltérhetnek. 
 
-A Kubernetes szoftver előtt telepítésre kell kerüljön a Docker a klaszter minden számítógépére. Ezt az Ubuntuban elérhető apt csomagkezelővel lehet telepíteni. Bár az alapértelmezett csomaggyűjteményben benne van a Docker egy verziója, ez a mérések megkezdésekor egy már nem támogatott verzió volt, ezért szükség volt a Docker fejlesztői által fenntartott csomaggyűjtemény telepítésére. Ezeket a lépéseket bash szkriptnyelven írt program segítségével lehet automatizálni. A majdani Masterre a telepítést parancsok szekvenciális végrehajtásával lehet, a Workerekre pedig ugyanezen parancsok ssh sztenderd bemenetére irányítva lehet végrehajtani. 
+A Kubernetes szoftver előtt telepítésre kell kerüljön a Docker a klaszter minden számítógépére. Ezt az Ubuntuban elérhető APT csomagkezelővel lehet telepíteni. Bár az alapértelmezett csomaggyűjteményben benne van a Docker egy verziója, ez a mérések megkezdésekor egy már nem támogatott verzió volt, ezért szükség volt a Docker fejlesztői által fenntartott csomaggyűjtemény telepítésére. Ezeket a lépéseket Bash szkriptnyelven írt program segítségével lehet automatizálni. A majdani Masterre a telepítést parancsok szekvenciális végrehajtásával lehet, a Workerekre pedig ugyanezen parancsok SSH sztenderd bemenetére irányítva lehet végrehajtani.
 
 A Kubernetes telepítése előtt az operációs rendszer lapozófájlját ki kell kapcsolni, ugyanis a Kubernetes csak akkor működik, ha a hostgépen nincs swap. Ezt egy paranccsal, valamint a swap a bekapcsoláskor betöltött partíciók közüli eltávolításával lehet elérni. 
 
-A Docker telepítése után a Kubernetes rendszert kezelő csomagok telepítése szükséges hasonló módon. A klaszter létrehozásához a kubeadm-et választottam, ugyanis az a referencia implementációja a Kubernetesnek. Az ebben a lépésben szükséges csomagok nem elérhetőek az alapértelmezett csomaggyűjteményben, így mindenképpen szükség van a Kubernetes fejlesztői által fenntartott csomaggyűjtemény telepítésére. Fontos, hogy mivel a Docker legújabb verziója került telepítésre, meg kell adni a kubeadm-nek, hogy ne ellenőrizze a telepített Docker verzióját. Ez nem jelent problémát, ugyanis a Docker API Kubernetes által használt része nem változott a legfrissebb, valamint a Kubernetes által ellenőrzött legfrissebb verzió között. Szintén fontos, hogy pontosan az 1.15.4-es verzió került telepítésre, ugyanis a mérések kezdetekor kiadott legfrissebb verzió -1.16- annyira új, hogy sem a Knative, sem a Kubeless nem támogatják, nem is működtek, ha 1.16-os verziójú klaszterbe próbáltam őket telepíteni. 
+A Docker telepítése után a Kubernetes rendszert kezelő csomagok telepítése szükséges hasonló módon. A klaszter létrehozásához a kubeadm-et választottam, ugyanis az a referencia implementációja a Kubernetes-nek. Az ebben a lépésben szükséges csomagok nem elérhetőek az alapértelmezett csomaggyűjteményben, így mindenképpen szükség van a Kubernetes fejlesztői által fenntartott csomaggyűjtemény telepítésére. Fontos, hogy mivel a Docker legújabb verziója került telepítésre, meg kell adni a kubeadm-nek, hogy ne ellenőrizze a telepített Docker verzióját. Ez nem jelent problémát, ugyanis a Docker API Kubernetes által használt része nem változott a legfrissebb, valamint a Kubernetes által ellenőrzött legfrissebb verzió között. Szintén fontos, hogy pontosan az 1.15.4-es verzió került telepítésre, ugyanis a mérések kezdetekor kiadott legfrissebb verzió - 1.16 - annyira új, hogy sem a Knative, sem a Kubeless nem támogatják, nem is működtek, ha 1.16-os verziójú klaszterbe próbáltam őket telepíteni. 
 
-A Master node telepítése során a kubeadm futtatásán, valamint a klaszter eléréséhez szükséges fájlok a felhasználó könyvtárába másolásán kívül egyéb teendő nincs, ugyanis Weavenet hálózati modul kerül később telepítésre. Miután a Master node sikeresen települt, a kubeadm eszköz segítségével ki kell nyerni a Workerek csatlakozásához szükséges tokent, valamint az openssl eszköz segítségével a Master nyilvános kulcsának hashét. 
+A Master node telepítése során a kubeadm futtatásán, valamint a klaszter eléréséhez szükséges fájlok a felhasználó könyvtárába másolásán kívül egyéb teendő nincs, ugyanis Weavenet hálózati modul kerül később telepítésre. Miután a Master node sikeresen települt, a kubeadm eszköz segítségével ki kell nyerni a Workerek csatlakozásához szükséges tokent, valamint az OpenSSL eszköz segítségével a Master nyilvános kulcsának hashét. 
 
 A Worker node telepítése során a két kinyert értéket, valamint a Master IP címét meg kell adni a kubeadm-nek. 
 
-Miután a klaszter minden tagja telepítésre került a további lépéseket a kubectl eszközzel lehet végre hajtani, ami a Masterre került telepítésre. Ahhoz, hogy a klaszterben lévő Podok kommunikálni tudjanak, szükség van egy hálózati beépülő modulra. Több ilyen létezik, szakdolgozatom során a Weavenetet választottam egyszerűsége miatt. Telepítése egy YAML leíró állomány applikálásával lehetséges.
+Miután a klaszter minden tagja telepítésre került a további lépéseket a kubectl eszközzel lehet végre hajtani, ami a Masterre került telepítésre. Ahhoz, hogy a klaszterben lévő podok kommunikálni tudjanak, szükség van egy hálózati beépülő modulra. Több ilyen létezik, szakdolgozatom során a Weavenetet választottam egyszerűsége miatt. Telepítése egy YAML leíró állomány applikálásával lehetséges.
 
 \subsection{Kubeless telep\'it\'ese}
-A Kubeless telepítése négy lépésből áll. Először a metrics-server nevű komponens telepítésére kerül sor. Erre a Kubeless által használt Horizontal Pod Autoscaler miatt van szükség, ugyanis ez a komponens gyűjti számára a metrikákat a Podokról. Ennek telepítése nem csak a fejlesztők által elkészített YAML állomány applikálásából áll, ugyanis a metrics-server alapértelmezés szerint mutual TLS protokollal titkosítja a kommunikációját a Kubernetes klaszterrel. Erre nincs szükség ebben a klaszterben, ezért ki lehet kapcsolni ezt a viselkedést, amit egy kapcsolóval lehet megtenni. Ez jól automatizálható sed program használatával. A módosított YAML fájlt már applikálni lehet. 
+A Kubeless telepítése négy lépésből áll. Először a metrics-server nevű komponens telepítésére kerül sor. Erre a Kubeless által használt Horizontal Pod Autoscaler miatt van szükség, ugyanis ez a komponens gyűjti számára a metrikákat a podokról. Ennek telepítése nem csak a fejlesztők által elkészített YAML állomány applikálásából áll, ugyanis a metrics-server alapértelmezés szerint mutual TLS protokollal titkosítja a kommunikációját a Kubernetes klaszterrel. Erre nincs szükség ebben a klaszterben, ezért ki lehet kapcsolni ezt a viselkedést, amit egy kapcsolóval lehet megtenni. Ez jól automatizálható \textit{sed} program használatával. A módosított YAML fájlt már applikálni lehet. 
 
-Ez után a második lépés az Nginx Ingress Controller telepítése. Itt nincs választási lehetőség, ugyanis a Kubelessbe ez a függőség erősen be van kötve. E komponens telepítéséhez két YAML állományt kell applikálni. Azért kettőt, mert van lehetőség menedzselt Kubernetes-be, valamint saját klaszterbe is telepíteni az Nginx Ingress Controllert. A két állomány közül az egyik minden Kubernetes környezet használata esetén alkalmazásra kell kerüljön, a másik pedig specifikus a felhasználó által használt Klaszter típusához, például Azure Kubernetes, vagy Google Container Engine és saját Kubernetes klaszterekhez külön-külön YAML állomány tartozik. 
+Ezután a második lépés az Nginx Ingress Controller telepítése. Itt nincs választási lehetőség, ugyanis a Kubeless-be ez a függőség erősen be van kötve. E komponens telepítéséhez két YAML állományt kell applikálni. Azért kettőt, mert van lehetőség menedzselt Kubernetes-be, valamint saját klaszterbe is telepíteni az Nginx Ingress Controllert. A két állomány közül az egyik minden Kubernetes környezet használata esetén alkalmazásra kell kerüljön, a másik pedig specifikus a felhasználó által használt Klaszter típusához, például Azure Kubernetes vagy Google Container Engine és saját Kubernetes klaszterekhez külön-külön YAML állomány tartozik. 
 
-A Kubeless könnyebb kezelése érdekében a harmadik telepítésre kerülő komponens a kubeless parancssori interfész. Ezt a programot már a fejlesztők lefordították, így csupán a megfelelő verzió beszerzése szükséges, annak egy olyan könyvtárba mozgatása, ahol a bash parancssori értelmező keresi a futtatható programokat, például a /usr/local/bin/ könyvtárba. 
+A Kubeless könnyebb kezelése érdekében a harmadik telepítésre kerülő komponens a kubeless parancssori interfész. Ezt a programot már a fejlesztők lefordították, így csupán a megfelelő verzió beszerzése szükséges, annak egy olyan könyvtárba mozgatása, ahol a Bash parancssori értelmező keresi a futtatható programokat, például a /usr/local/bin/ könyvtárba. 
 
-Negyedik és utolsó lépésként a Kubeless klaszterbe telepítésére kerül sor. Ehhez létre kell hozni egy új névteret a kubectl segítségével. Ez után lehet applikálni a Kubeless fejlesztői által elkészített YAML állományt. 
+Negyedik és utolsó lépésként a Kubeless klaszterbe telepítésére kerül sor. Ehhez létre kell hozni egy új névteret a kubectl segítségével. Ezután lehet applikálni a Kubeless fejlesztői által elkészített YAML állományt. 
 
-Az itt leírt lépések bash szkript segítségével automatizálhatók.
+Az itt leírt lépések Bash szkript segítségével automatizálhatók.
 
 \subsection{Knative telep\'it\'ese}
-A Knative telepítése kevesebb komponens feltelepítéséből áll, azok telepítése viszont bonyolultabb. A rendszer telepítése előtt installálni kell az Istiot. Ezt a helm nevű Kubernetes-hez készített csomagkezelő rendszer segítségével lehet, viszont a helmet is installálni kell. Ez az Ubuntu rendszerben lévő snap csomagkezelővel telepíthető. A snap abban különbözik az apt-tól, hogy az általa telepített csomagok és a függőségeik a rendszercsomagoktól és a rendszerben jelen lévő osztott könyvtáraktól függetlenek, de hatással lehetnek a rendszerre. 
+A Knative telepítése kevesebb komponens feltelepítéséből áll, azok telepítése viszont bonyolultabb. A rendszer telepítése előtt installálni kell az Istiot. Ezt a Helm nevű Kubernetes-hez készített csomagkezelő rendszer segítségével lehet, viszont a Helmet is installálni kell. Ez az Ubuntu rendszerben lévő Snap csomagkezelővel telepíthető. A Snap abban különbözik az APT-tól, hogy az általa telepített csomagok és a függőségeik a rendszercsomagoktól és a rendszerben jelen lévő osztott könyvtáraktól függetlenek, de hatással lehetnek a rendszerre. 
 
-A helm telepítése után inicializálni kell, amely az úgynevezett Tiller a Kubernetes-be telepítését, valamint információegyeztetést a Tiller és a helm között jelenti. Viszont ahhoz, hogy a Tiller a klaszterben a kívánt módosításokat el tudja végezni meg kell neki adni a megfelelő jogosultságokat. Erre úgy van lehetőség, hogy létre kell hozni egy új, úgynevezett Service Accountot, amely hasonlóan viselkedik a felhasználói fiókokhoz, viszont ezt Podokhoz lehet rendelni. A létrehozott Service Accounthoz pedig a cluster-admin jogosultságot kell rendelni. Ennél lehet kevesebb jogot adni a Tillernek, viszont egyetlen felhasználója lesz a klaszternek, így nincs szükség finomhangolt jogosultságkezelésre. Csak e két lépés után lehet inicializálni a helmet, valamint a Tillert. 
+A Helm telepítése után inicializálni kell, amelyhez elengedhetetlen a Tiller telep\'it\'ese a Kubernetes-be, valamint információegyeztetés a Tiller és a Helm között. Viszont ahhoz, hogy a Tiller a klaszterben a kívánt módosításokat el tudja végezni meg kell neki adni a megfelelő jogosultságokat. Erre úgy van lehetőség, hogy létre kell hozni egy új, úgynevezett Service Accountot, amely hasonlóan viselkedik a felhasználói fiókokhoz, viszont ezt podokhoz lehet rendelni. A létrehozott Service Accounthoz pedig a cluster-admin jogosultságot kell rendelni. Ennél lehet kevesebb jogot adni a Tillernek, viszont egyetlen felhasználója lesz a klaszternek, így nincs szükség finomhangolt jogosultságkezelésre. Csak e két lépés után lehet inicializálni a Helmet, valamint a Tillert. 
 
-Az Istio telepítésének megkezdése előtt létre kell hozni az általa bevezetett új objektumtípusokat, valamint egy külön névteret, ahova az Istio rendszer saját objektumai kerülhetnek. Ez számos YAML állomány applikálását jelenti. Ez után az Istio rendszert telepítő YAML állományt ki kell generáltatni a helmmel. A generálásnál lehetőség van megadni, az Istio mely komponensei ne települjenek. Nincs szükségünk például monitoring rendszerre, telemetria és jogosultságkezelő rendszerre. Ezeket parancssori paraméterrel lehet megadni. A generálás után létrehozott YAML fájl által leírt módosítások végrehajtását a megszokott módon kell végrehajtani. 
+Az Istio telepítésének megkezdése előtt létre kell hozni az általa bevezetett új objektumtípusokat, valamint egy külön névteret, ahova az Istio rendszer saját objektumai kerülhetnek. Ez számos YAML állomány applikálását jelenti. Ezután az Istio rendszert telepítő YAML állományt ki kell generáltatni a Helmmel. A generálásnál lehetőség van megadni, az Istio mely komponensei ne települjenek. Nincs szükségünk például monitoring rendszerre, telemetria és jogosultságkezelő rendszerre. Ezeket parancssori paraméterrel lehet megadni. A generálás után létrehozott YAML fájl által leírt módosítások végrehajtását a megszokott módon kell végrehajtani. 
 
-Miután az Istio feltelepült, a Knative által bevezetett objektumtípusok létrehozása következik. Ezt a lépést kétszer kell végrehajtani egy a fejlesztők által ismert hiba miatt. Az első végrehajtás során néhány objektumtípus nem jön létre, másodszorra viszont ezek is létrejönnek, és a már létező objektumtípusok nem módosulnak. Végül a Knative rendszer telepíthető a fejlesztők által elkészített YAML állomány applikálásával hasonlóan a korábbi rendszerekhez.
+Miután az Istio feltelepült, a Knative által bevezetett objektumtípusok létrehozása következik. Ezt a lépést kétszer kell végrehajtani egy, a fejlesztők által ismert hiba miatt. Az első végrehajtás során néhány objektumtípus nem jön létre, másodszorra viszont ezek is telep\"ulnek, és a már létező objektumtípusok nem módosulnak. Végül a Knative rendszer telepíthető a fejlesztők által elkészített YAML állomány applikálásával hasonlóan a korábbi rendszerekhez.
 
 \section{M\'er\'esi eszk\"oz\"ok kiv\'alaszt\'asa}
-Számos http végpontok teljesítményének mérésére szolgáló eszköz létezik. A használt eszközök kiválasztása előtt fontos megnevezni a szempontokat, amik alapján a használt eszközök kiválasztásra kerültek. 
+Számos HTTP végpontok teljesítményének mérésére szolgáló eszköz létezik. A használt eszközök kiválasztása előtt fontos megnevezni a szempontokat, amik alapján a használt eszközök kiválasztásra kerültek. 
 
-A legfontosabb, hogy a ráta, amivel a kéréseket képes generálni legalább érje el a mérni kívánt http végpont áteresztőképességét. Amennyiben ez nem teljesül, az adott eszközt nem érdemes használni. 
+A legfontosabb, hogy a ráta, amivel a kéréseket képes generálni legalább érje el a mérni kívánt HTTP végpont áteresztőképességét. Amennyiben ez nem teljesül, az adott eszközt nem érdemes használni. 
 
-Szintúgy fontos szempont, hogy az eszköz képes legyen minden visszaérkező válaszról információt valamilyen automatikusan feldolgozható formátumban - például csv, vagy xml - menteni. Ez azért fontos, mert a mérések elvégzése és az adatok feldolgozásának automatizálása cél volt, ha ezt egy eszköz nem támogatja, nem használható a mérések során. 
+Szintúgy fontos szempont, hogy az eszköz képes legyen minden visszaérkező válaszról információt valamilyen automatikusan feldolgozható formátumban - például csv vagy xml - menteni. Ez azért fontos, mert a mérések elvégzése és az adatok feldolgozásának automatizálása cél volt, ha ezt egy eszköz nem támogatja, nem használható a mérések során. 
 
 A végső szempont a megfelelő dokumentáció elérhetősége. Hiába felel meg egy eszköz mindkét korábban részletezett szempontnak, amennyiben nem érhető el hozzá dokumentáció, egyrészt a funkcióinak teljes tárháza sem feltétlen megismerhető, működésének elsajátítása pedig aránytalanul nehéz lehet. 
 
-A megfelelő mérési eszköz kiválasztásához számos eszközt megvizsgáltam.
+A megfelelő mérési eszköz kiválasztásához számos eszközt megvizsgáltam, melyeket a k\"ovetkező pontokban fejtek ki.
 
 \subsection{Wrk}
-A wrk egy C-ben írt, nyílt forráskódú http teljesítménymérő szoftver. Többszálú designjának köszönhetően nagy sebességgel képes generálni a kéréseket. A használt kapcsolat objektumok és szálak száma parancssori kapcsoló segítségével beállítható, valamint működésének bizonyos aspektusai Lua szkriptnyelven testreszabhatók. Egyetlen hátránya, hogy bár a kimeneti formátumot Lua-ban írt szkript segítségével testre lehet szabni, nincs lehetőség minden kérés, vagy bizonyos időközönként átlagolt részeredmény exportálására. Mivel a wrk az általam vizsgált megoldások közül az egyik legrégebb óta fejlesztett, a hozzá elérhető dokumentáció kitér a gyakran előforduló problémákra, valamint a szkriptelést megkönnyítik a fejlesztők által előre elkészített példák. A wrk a mérés végeztével egyszer menti a másodpercenkénti átlagos kérések számát, amire érkezett valamilyen válasz, valamint egyebek mellett az átlagos kérleltetést, amivel a válasz megérkezett. 
+A wrk egy C-ben írt, nyílt forráskódú HTTP teljesítménymérő szoftver. Többszálú designjának köszönhetően nagy sebességgel képes generálni a kéréseket. A használt kapcsolat objektumok és szálak száma parancssori kapcsoló segítségével beállítható, valamint működésének bizonyos aspektusai Lua szkriptnyelven testreszabhatók. Egyetlen hátránya, hogy bár a kimeneti formátumot Lua-ban írt szkript segítségével testre lehet szabni, nincs lehetőség minden kérés vagy bizonyos időközönként átlagolt részeredmény exportálására. Mivel a wrk az általam vizsgált megoldások közül az egyik legrégebb óta fejlesztett, a hozzá elérhető dokumentáció kitér a gyakran előforduló problémákra, valamint a szkriptelést megkönnyítik a fejlesztők által előre elkészített példák. A wrk a mérés végeztével egyszer menti a másodpercenkénti átlagos kérések számát, amire érkezett valamilyen válasz, valamint egyebek mellett az átlagos k\'er\'es r\'at\'at, amivel a válasz megérkezett. 
 
 Emiatt a wrk nem volt alkalmas a mérések elvégzésére.
 
 \subsection{Hey}
-A hey egy Go nyelven írt, nyílt forráskódú http terhelés generáló. Eredetileg az ApacheBench cseréjére hozták létre, emiatt parancssori interfésze igen hasonló. Mivel Go-ban készült, az általa elérhető teljesítmény potenciálisan nagy. A használt kapcsolat objektumokat, valamint esetleges ráta limitet parancssori kapcsolóval meg lehet adni. A megadott limit kapcsolat objektumonként értelmezett. Tehát százas ráta limit esetén két kapcsolat használatával a hey által másodpercenként generált kérések száma kétszáz. Lehetőség van a hosztnév fejléc, valamint a kérés törzsének megadására, szintén parancssori kapcsolóval. 
+A hey egy Go nyelven írt, nyílt forráskódú HTTP terhelésgeneráló. Eredetileg az ApacheBench cseréjére hozták létre, emiatt parancssori interfésze igen hasonló. Mivel Go-ban készült, az általa elérhető teljesítmény potenciálisan nagy. A használt kapcsolat objektumokat, valamint esetleges ráta limitet parancssori kapcsolóval meg lehet adni. A megadott limit kapcsolat objektumonként értelmezett. Tehát százas ráta limit esetén két kapcsolat használatával a hey által másodpercenként generált kérések száma kétszáz. Lehetőség van a hosztnév fejléc, valamint a kérés törzsének megadására, szintén parancssori kapcsolóval. 
 
-Alapértelmezés szerint a hey is hasonló összefoglalót generál, mint a wrk, viszont azzal ellentétben a hey képes minden kérésről exportálni többek között, hogy az indítástól kezdve mikor és milyen késleltetéssel ért vissza, valamint a szerver milyen http kóddal válaszolt. Hátránya viszont, hogy egyszerre csak tízmillió választ képes tárolni, amely hosszabb mérések esetén azt jelenti, több rövidebb almérésre kell bontani a mérést. Bár a hozzá elérhető dokumentáció csak az elérhető parancssori kapcsolók, valamint azok paramétereiig terjed ki, belső működése egyszerűsége okán ennél többre nincs szükség a használatához. 
+Alapértelmezés szerint a hey is hasonló összefoglalót generál, mint a wrk, viszont azzal ellentétben a hey képes minden kérésről exportálni többek között, hogy az indítástól kezdve mikor és milyen késleltetéssel ért vissza, valamint a szerver milyen HTTP kóddal válaszolt. Hátránya viszont, hogy egyszerre csak tízmillió választ képes tárolni, amely hosszabb mérések esetén azt jelenti, több rövidebb almérésre kell bontani a mérést. Bár a hozzá elérhető dokumentáció csak az elérhető parancssori kapcsolók, valamint azok paramétereiig terjed ki, belső működése egyszerűsége okán ennél többre nincs szükség a használatához. 
 
 A leírtak miatt úgy döntöttetem, a mérések során a hey-t használom.
 
 \subsection{Loadtest}
-A Loadtest egy Javascript nyelven, Node.Js környezetben írt nyílt forráskódú http teljesítménymérő. Lényeges előnye a hey-jel szemben, hogy a kérések kiküldése előtt nem várja meg az adott konkurencia objektum, hogy megérkezzen a válasz. Jelentős hátrány, hogy csak egy szálat használ, így az általa generált másodpercenkénti kérések száma jelentősen alacsonyabb, mint az általam vizsgált többi eszközé. Emellett a Loadtest is csak a mérés végeztével generál egy összefoglaló riportot, nem képes a kérésekről adatok exportálására. A hozzá elérhető dokumentáció alapján használata egyszerű, valamint a belső működés könnyedén megérthető. Ezek miatt a Loadtestet nem találtam alkalmasnak a mérések elvégzésére.
+A Loadtest egy Javascript nyelven, Node.Js környezetben írt nyílt forráskódú HTTP teljesítménymérő. Lényeges előnye a hey-jel szemben, hogy a kérések kiküldése előtt nem várja meg az adott konkurencia objektum, hogy megérkezzen a válasz. Jelentős hátránya, hogy csak egy szálat használ, így az általa generált másodpercenkénti kérések száma jelentősen alacsonyabb, mint az általam vizsgált többi eszközé. Emellett a Loadtest is csak a mérés végeztével generál egy összefoglaló riportot, nem képes a kérésekről adatok exportálására. A hozzá elérhető dokumentáció alapján használata egyszerű, valamint a belső működés könnyedén megérthető. Ezek miatt a Loadtestet nem találtam alkalmasnak a mérések elvégzésére.
 
 \subsection{Apache Jmeter}
-Az Apache Jmeter, vagy Jmeter egy Java 8-as verziójában íródott, nyílt forráskódú, testre szabható webes teljesítménymérő. Fő tulajdonsága, hogy saját mérési tervet lehet segítségével összeállítani, majd végrehajtani azt. A mérési tervet egy grafikus felületen lehet összeállítani. Lehetőség van definiálni több felhasználói csoportot, ahonnan a terhelés érkezik, valamint az egyes felhasználók által küldött paraméterek is testre szabhatók. Egy méréshez legalább egy felhasználói csoportot meg kell adni, valamint http végpont teljesítményének mérése esetén egy HTTP Request objektum definiálása szükséges. Ha az eredményeket látni akarjuk, akkor a megtekintés szerint kívánt formátumú Listenert kell definiálni. Fontos, hogy http fejlécek küldése esetén még hozzá kell adni egy HTTP Header Manager komponenst, amelyben tetszőleges számú fejlécet lehet definiálni kulcs-érték párban. A Jmeter képes grafikonon ábrázolni az érzékelt késleltetés időbeni alakulását, valamint minden kérésről exportálni tudja többek között a kapott http státusz kódot, a mért késleltetést, valamint a kérés küldésének pontos idejét. Mivel egy Javaban írt programról van szó, a teljesítménye jelentősen függ a Java virtuális gép számára elérhető memóriától, valamint a használt Garbage Collector algoritmustól. 
+Az Apache Jmeter vagy Jmeter egy Java 8-as verziójában íródott, nyílt forráskódú, testre szabható webes teljesítménymérő. Fő tulajdonsága, hogy saját mérési tervet lehet segítségével összeállítani, majd végrehajtani azt. A mérési tervet egy grafikus felületen lehet összeállítani. Lehetőség van definiálni több felhasználói csoportot, ahonnan a terhelés érkezik, valamint az egyes felhasználók által küldött paraméterek is testre szabhatók. Egy méréshez legalább egy felhasználói csoportot meg kell adni, valamint HTTP végpont teljesítményének mérése esetén egy HTTP Request objektum definiálása szükséges. Ha az eredményeket látni akarjuk, akkor a megtekintés szerint kívánt formátumú Listenert kell definiálni. Fontos, hogy HTTP fejlécek küldése esetén még hozzá kell adni egy HTTP Header Manager komponenst, amelyben tetszőleges számú fejlécet lehet definiálni kulcs-érték párban. A Jmeter képes grafikonon ábrázolni az érzékelt késleltetés időbeni alakulását, valamint minden kérésről exportálni tudja többek között a kapott HTTP státusz kódot, a mért késleltetést, valamint a kérés küldésének pontos idejét. Mivel egy Javaban írt programról van szó, a teljesítménye jelentősen függ a Java virtuális gép számára elérhető memóriától, valamint a használt Garbage Collector algoritmustól. 
 
-A Jmeter igen elterjedt szoftver, viszont kifejezetten bonyolult, szerencsére a hozzá elérhető dokumentáció az összes általam vizsgált eszköz közül a legrészletesebb. Mivel a Jmeter működése eltér a hey-től, valamint a kritériumoknak megfelel, úgy döntöttem a méréseket mindkét eszközzel elvégzem.
+A Jmeter igen elterjedt szoftver, viszont kifejezetten bonyolult, szerencsére a hozzá elérhető dokumentáció az összes általam vizsgált eszköz közül a legrészletesebb volt. Mivel a Jmeter működése eltér a hey-től, valamint a kritériumoknak megfelel, úgy döntöttem a méréseket mindkét eszközzel elvégzem.
 
 \section{M\'er\'esek automatiz\'al\'asa}
-A mérőeszközök kiválasztása után magukat a méréseket dolgoztam ki. Az egyértelmű volt, hogy konstans terhelésű mérést mindenképpen kell végezzek. A Kubeless esetén, mivel skálázása csak a cpu terheléstől függ, a skálázás megfigyelésére az ilyen típusú mérések elégségesek lehetnek. Ezzel szemben a Knative konkurencia alapú skálázásának megfigyelésére a bemeneti oldali konkurens kérések folyamatos növelése az előző típusú mérés mellett érdekesnek bizonyulhat. 
+A mérőeszközök kiválasztása után magukat a méréseket dolgozhattam ki. Az egyértelmű volt, hogy konstans terhelésű mérést mindenképpen kell végezzek. Kubeless esetén mivel skálázása csak a cpu terheléstől függ, a skálázás megfigyelésére az ilyen típusú mérések elégségesek lehetnek. Ezzel szemben a Knative konkurencia alapú skálázásának megfigyelésére a bemeneti oldali konkurens kérések folyamatos növelése az előző típusú mérés mellett érdekesnek bizonyulhat. 
 
-Mivel a méréseket nem egyszerre végeztem, valamint a mérések elvégzéséhez a hey esetében a megfelelő parancssori kapcsolók lánca hosszú, szükségét láttam annak, hogy legalább a hey esetében egy bash szkript segítségével automatizáljam a mérések elvégzését. A Jmeter esetében erre nincs szükség, hála az előre elkészíthető mérési terveknek. 
+Mivel a méréseket nem egyszerre végeztem, valamint a mérések elvégzéséhez a hey esetében a megfelelő parancssori kapcsolók lánca hosszú, szükségét láttam annak, hogy legalább a hey esetében egy Bash szkript segítségével automatizáljam a mérések elvégzését. A Jmeter esetében erre nincs szükség, hála az előre elkészíthető mérési terveknek. 
 
-A bash szkript megírásánál a hey automatizált telepítése is fontos volt, ugyanis a munkám során több klaszteren is dolgoztam. Annak érdekében, hogy a mérések paraméterei testre szabhatók legyenek, a 
+A Bash szkript megírásánál a hey automatizált telepítése is fontos volt, ugyanis a munkám során több klaszteren is dolgoztam. Annak érdekében, hogy a mérések paraméterei testre szabhatók legyenek, a 
 \begin{itemize}
  \item mérendő függvények nevét,
  \item használandó connection objektumok számát,
@@ -95,34 +95,34 @@ A bash szkript megírásánál a hey automatizált telepítése is fontos volt,
 
 A mérendő függvények nevét egy tömbben tároltam, így egymás után több mérés is elvégezhető ugyanazon paraméterekkel. A mérés típusát egy parancssori kapcsolóval lehet kiválasztani. Annak érdekében, hogy a szkript használatát kényelmessé tegyem, úgy döntöttem, mindkét típusú mérést el lehet végezni egy futtatással. A szkript elkészítésénél igyekeztem figyelni arra, hogy új típusú mérés bevezetéséhez ne legyen szükséges olyan részeket módosítani, amik nem kapcsolódnak közvetlen az új funkcionalitáshoz.
 
-A folyamatos terhel\'est gener\'al\'o m\'er\'es \aref{code:bash-banchmark-for} k\'odr\'eszleten l\'athat\'o. A hey saj\'at\'oss\'agai miatt alkalmaztam azt a megold\'ast, hogy a k\'iv\'ant hossz\'us\'ag\'u fut\'as el\'er\'ese \'erdek\'eben t\"obbsz\"or elind\'itottam az eszk\"ozt. Látható, hogy a Kubeless-be és a Knative-ba telepített függvények meghívása eltér nem csak az alkalmazott http metódusban és a hosztnév sémájában, de a Content-Type fejléc, melynek értékét a –T kapcsolóval lehet megadni, megléte is különbözik. 
+A folyamatos terhel\'est gener\'al\'o m\'er\'es \aref{code:bash-banchmark-for} f\"uggel\'ekben l\'athat\'o. A hey saj\'atoss\'agai miatt alkalmaztam azt a megold\'ast, hogy a k\'iv\'ant hossz\'us\'ag\'u fut\'as el\'er\'ese \'erdek\'eben t\"obbsz\"or elind\'itottam az eszk\"ozt. Látható, hogy a Kubeless-be és a Knative-ba telepített függvények meghívása eltér nem csak az alkalmazott HTTP metódusban és a hosztnév sémájában, de a Content-Type fejléc, melynek értékét a –T kapcsolóval lehet megadni, megléte is különbözik. 
 
 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.
+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 fel\'e, egy \'allom\'anyba r\"ogz\'iti a v\'alaszidőt, majd k\"ozvetlen ezut\'an ism\'etelten k\'er\'est k\"uld \'es egy m\'asik \'allom\'anyba r\"ogz\'iti ezt a v\'alaszidőt. Az \'altalam k\'esz\'itett szkript pontosan k\'et percet v\'ar. 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. 
+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 a 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. 
 
-A program célja az volt, hogy az összes összegyűjtött mérésből generáljon diagrammokat, melyeken ábrázolja a függvény által feldolgozott kérések másodpercenkénti számát, valamint később a másodpercenkénti átlagos késleltetés időbeni alakulását a mérés során. Szintén a munka közben merült fel az igény, hogy a Knative Autoscaler komponensének naplófájlja alapján az általa érzékelt konkurencia és a létrehozott Podok számának alakulását is nyomon kövesse a program. 
+A program célja az volt, hogy az összes összegyűjtött mérésből generáljon diagrammokat, melyeken ábrázolja a függvény által feldolgozott kérések másodpercenkénti számát, valamint később a másodpercenkénti átlagos késleltetés időbeni alakulását a mérés során. Szintén a munka közben merült fel az az igény, hogy a Knative Autoscaler komponensének naplófájlja alapján az általa érzékelt konkurencia és a létrehozott podok számának alakulását is nyomon kövesse a program. 
 
-Mivel egy méréshez több állomány is tartozhat, az egybe tartozó állományok egy mappába kerültek. A mappa neve reflektálja a mérőeszköz nevét, a mért rendszer és függvény nevét. Például a jmeter-knative-hello-scale-1 egy lehetséges mappanév. Az így strukturált adatok feldolgozása nem függ másik méréstől. A program indulása után az adatokat tartalmazó mappákat kigyűjti, majd a jmeter kulcsszót tartalmazó mappák feldolgozását továbbítja a Jmeter kimenetét feldolgozni képes objektumnak. Az összes többi könyvtárat pedig a hey által generált állományok feldolgozásáért felelő objektumnak továbbítja. Mivel a Knative Autoscaler naplófájljainak feldolgozása, mint igény, később jelent meg, a könyvtárak neve nem jelzi, hogy az adott objektum számára tartalmaz-e releváns információt, ezért az minden mappa tartalmát megvizsgálja, tartalmaz-e általa feldolgozandó állományokat. 
+Mivel egy méréshez több állomány is tartozhat, az egybe tartozó állományok egy mappába kerültek. A mappa neve reflektálja a mérőeszköz nevét, a mért rendszer és függvény nevét. Például a \textit{jmeter-knative-hello-scale-1} egy lehetséges mappanév. Az így strukturált adatok feldolgozása nem függ másik méréstől. A program indulása után az adatokat tartalmazó mappákat kigyűjti, majd a \textit{jmeter} kulcsszót tartalmazó mappák feldolgozását továbbítja a Jmeter kimenetét feldolgozni képes objektumnak. Az összes többi könyvtárat pedig a hey által generált állományok feldolgozásáért felelő objektumnak továbbítja. Mivel a Knative Autoscaler naplófájljainak feldolgozása, mint igény, később jelent meg, a könyvtárak neve nem jelzi, hogy az adott objektum számára tartalmaz-e releváns információt, ezért az minden mappa tartalmát megvizsgálja, hogy tartalmaz-e általa feldolgozandó állományokat. 
 
 Ahogy \aref{code:jmeter-analyze} kódrészleten látszik, hogy a Python eléggé megkönnyíti egy csv fájl feldolgozását. A csv.reader függvény egy generátorral tér vissza, melyen végig iterálva lehet soronként feldolgozni az állományt. Egy sort a Python egy tuple objektumként reprezentál. Az első sorban az oszlopok nevét adja meg a Jmeter, így azt külön tuple objektumba mentve a zip hívással egy dictionary-t kapunk. Ebből a kívánt oszlop nevét megadva lehet kinyerni a keresett mezőt. 
 
-A JmeterAnalyzer objektum létrejöttekor létrehoz egy dictionary objektumot, melyben a beolvasott fájl timeStamp mezője lesz a kulcs, az érték pedig az adott másodpercben érzékelt válaszok körbefordulási ideje. Mivel a Jmeter egy Java-ban írt szoftver, a timeStamp mező egy java.utils.Date objektum szerializálva. Ahhoz, hogy ebből Python datetime objektumot lehessen készíteni, az adott számot el kell osztani ezerrel. Az így kapott datetime már másodperc pontosan fogja tárolni az időt. Az adott másodpercben visszaérkezett válaszok számát pedig az adott másodpercben tárolt késleltetési értékek száma adja meg. 
+A JmeterAnalyzer objektum létrejöttekor létrehoz egy dictionary objektumot, melyben a beolvasott fájl \textit{timeStamp} mezője lesz a kulcs, az érték pedig az adott másodpercben érzékelt válaszok körbefordulási ideje. Mivel a Jmeter egy Java-ban írt szoftver, a timeStamp mező egy java.utils.Date objektum szerializálva. Ahhoz, hogy ebből Python datetime objektumot lehessen készíteni, az adott számot el kell osztani ezerrel. Az így kapott datetime már másodperc pontosan fogja tárolni az időt. Az adott másodpercben visszaérkezett válaszok számát pedig az adott másodpercben tárolt késleltetési értékek száma adja meg. 
 
 A feldolgozás végeztével egy-egy listába kigyűjti a másodpercenként összegyűjtött adatokat tartalmazó listák hosszát, valamint az értékek átlagát. 
 
-Amint \aref{code:hey-analyze} hey esetében máshogy kell csinálni, ugyanis itt a mérés több fájlra bomlik, amelyekben viszont nem lehet feltételezni, hogy pontosan harminc másodpercnyi, vagy egyéb konstans időtartamnyi mérés adatát tartalmazza egy-egy fájl, ugyanis a munka során ez változott. Emiatt egy fájl feldolgozása után gyűjti ki két listába az összegyűjtött adatokat tartalmazó lista hosszát és a késleltetések átlagát. 
+Amint \aref{code:hey-analyze} f\"uggel\'ekben l\'athat\'o, hey esetében a feldolgoz\'ast máshogy kell csinálni, ugyanis itt a mérés több fájlra bomlik, amelyekben viszont nem lehet feltételezni, hogy pontosan 30 másodpercnyi vagy egyéb konstans időtartamnyi mérés adatát tartalmazza egy-egy fájl. Ugyanis a munka során ez változott. Emiatt egy fájl feldolgozása után gyűjti ki két listába az összegyűjtött adatokat tartalmazó lista hosszát és a késleltetések átlagát. 
 
-Miután a Knative Autoscaler naplóállománya analizálásának igénye felmerült, a méréseket automatizáló bash szkript módosítva lett úgy, hogy minden mérés kezdetének és végeztének másodpercre pontos dátumát egy külön fájlba menti. Ez által a naplófájl bejegyzéseit lehet szűrni a két dátum köztire. 
+Miután a Knative Autoscaler naplóállománya analizálásának igénye felmerült, a méréseket automatizáló Bash szkript módosítva lett úgy, hogy minden mérés kezdetének és végeztének másodpercre pontos dátumát egy külön fájlba menti. Ez által a naplófájl bejegyzéseit lehet szűrni a két dátum köztire. 
 
-A Knative Autoscaler a naplóbejegyzéseket json objektumként menti, melyből a Python képes dictionary objektumot készíteni. Amennyiben az adott bejegyzés ts mezője a mérés kezdési és befejezési ideje közé esik, akkor az msg mezőben lévő üzenet feldolgozásra kerül. Az üzenetben kulcs-érték párok vannak szóközzel elválasztva egymástól. A kulcs és az érték között egyenlőségjel van. Ezt egy reguláris kifejezéssel listává lehet konvertálni. Sajnos a Python reguláris kifejezés API-jában nincs arra lehetőség, hogy ilyen esetben dictionary objektumot adjon vissza, így azt kézzel kell konvertálni kihasználva azt, hogy az értékek mindig egy kulcs után következnek. Ezután a Podok száma, valamint a megfigyelt stabil konkurencia érték letárolható. Ennek folyamat\'at \aref{sec:log-analyze} f\"uggel\'ekben l\'atni.
+A Knative Autoscaler a naplóbejegyzéseket JSON objektumként menti, melyből a Python képes dictionary objektumot készíteni. Amennyiben az adott bejegyzés \textit{ts} mezője a mérés kezdési és befejezési ideje közé esik, akkor az \textit{msg} mezőben lévő üzenet feldolgozásra kerül. Az üzenetben kulcs-érték párok vannak szóközzel elválasztva egymástól. A kulcs és az érték között egyenlőségjel van. Ezt egy reguláris kifejezéssel listává lehet konvertálni. Sajnos a Python reguláris kifejezés API-jában nincs arra lehetőség, hogy ilyen esetben dictionary objektumot adjon vissza, így azt kézzel kell konvertálni kihasználva azt, hogy az értékek mindig egy kulcs után következnek. Ezután a podok száma, valamint a megfigyelt stabil konkurencia érték letárolható. Ennek folyamat\'at \aref{sec:log-analyze} f\"uggel\'ekben l\'atni.
 
-A feldolgozott adatokból a matplotlib Python könyvtár segítségével készíthető grafikon úgy, hogy az adatokat tartalmazó listát átadjuk a megfelelő függvény számára. A grafikon mentése egy másik függvényhívással lehetséges. Szintén külön függvényhívással lehet a grafikon címét, valamint a tengelyek feliratát elhelyezni a grafikonon.
+A feldolgozott adatokból a \textit{matplotlib} Python könyvtár segítségével készíthető grafikon úgy, hogy az adatokat tartalmazó listát átadjuk a megfelelő függvény számára. A grafikon mentése egy másik függvényhívással lehetséges, szintén külön függvényhívással lehet a grafikon címét \'es a tengelyek feliratát elhelyezni.
 
-A méréseket elvégző szkript kis módosításával elértem, hogy a mérési eredmények egy általam üzemeltett számítógépre töltődjenek fel archiválásra és az itt részletezett program által feldolgozásra. A feltöltés után a szkript meghívott egy ugyanezen a szerveren futó REST-es végpontot, amely hatására elindult az adatok feldolgozása. Maga a program egy Docker konténerben futott. A kód verziókövetésére Git-et használtam, amelynek előnye az volt, hogy minden alkalommal, mikor egy állapotát mentettem a kódnak, abból a Travis szolgáltatás automatikusan elkészítette a Docker Image-et, valamint feltöltötte a Docker Hub-ra. Így a fejlesztéstől a mérésig teljesen automatizált munkafolyamatot dolgoztam ki. Felmerült ötletként, hogy ezt a Knative rendszerbe telepítsem, viszont szerettem volna, ha a méréseket feldolgozó folyamat független a mért rendszertől és a lehető leglazábban kapcsolódik hozzá. Ez által a két rendszerben történő folyamatok, esetleges hibák nem hatnak ki a másik működésére. 
+A méréseket elvégző szkript kis módosításával elértem, hogy a mérési eredmények egy általam üzemeltett számítógépre töltődjenek fel archiválásra és az itt részletezett program által feldolgozásra. A feltöltés után a szkript meghívott egy ugyanezen a szerveren futó REST-es végpontot, amely hatására elindult az adatok feldolgozása. Maga a program egy Docker konténerben futott. A kód verziókövetésére Git-et használtam, amelynek előnye az volt, hogy minden alkalommal, mikor egy állapotát mentettem a kódnak, abból a Travis szolgáltatás automatikusan elkészítette a Docker Image-et, valamint feltöltötte a Docker Hub-ra. Így a fejlesztéstől a mérésig teljesen automatizált munkafolyamatot dolgoztam ki. Felmerült ötletként, hogy ezt a Knative rendszerbe telepítsem, viszont szerettem volna, ha a méréseket feldolgozó folyamat független a mért rendszertől és a lehető leglazábban kapcsolódjon hozzá. Ezáltal a két rendszerben történő folyamatok, esetleges hibák nem hatnak ki a másik működésére. 
 
-Miután a késleltetést is grafikonon akartam ábrázolni, számos mérési eredményt újra fel kellett dolgozni, ami az adatok nagy mennyisége miatt sok időt vett igénybe. Viszont felismerve, hogy a mérések között nincs függőség, minden könyvtár feldolgozását külön process-ekre bontottam. Kimondottan nem szálakat használtam, ugyanis a Pythonban közismert probléma a Global Interpreter Lock, ami miatt a Python egyszerre csak egy szál éppen futó kódját értelmezi. Amennyiben az adott feladat számára teljesen önálló process indul, annak saját GIL-je lesz, ezzel megoldva ezt a problémát. Ez által a feldolgozási idő kevesebb, mint felére csökkent.
+Miután a késleltetést is grafikonon akartam ábrázolni, számos mérési eredményt újra fel kellett dolgozni, ami az adatok nagy mennyisége miatt sok időt vett igénybe. Viszont felismerve, hogy a mérések között nincs függőség, minden könyvtár feldolgozását külön process-ekre bontottam. Kimondottan nem szálakat használtam, ugyanis a Pythonban közismert probléma a Global Interpreter Lock, ami miatt a Python egyszerre csak egy szál éppen futó kódját értelmezi. Amennyiben az adott feladat számára teljesen önálló process indul, annak saját GIL-je lesz, ezzel megoldva ezt a problémát. \'Igy a feldolgozási idő kevesebb, mint a felére csökkent.
diff --git a/src/content/results.tex b/src/content/results.tex
index b23dfdd..32f6947 100644
--- a/src/content/results.tex
+++ b/src/content/results.tex
@@ -2,9 +2,9 @@
 
 \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. 
+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 eszk\"ozzel megmértem mind a kettő 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 45. 
 
-Az \ref{fig:docker-chart} ábrából látszik, hogy 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. Ha ezt nem l\'eptem meg, a hey sz\'azhatvanezer k\'er\'est volt k\'epes gener\'alni m\'asodpercenk\'ent. Ezek mellett, ú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. 
+Az \ref{fig:docker-chart} ábrából látszik, hogy a Jmeter jobban teljesített, mint a hey. Ez azért van, mert a hey-re megszabtam connection objektumomként 500 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. Ha ezt nem l\'eptem volna meg, a hey sz\'azhatvanezer k\'er\'est volt k\'epes gener\'alni m\'asodpercenk\'ent. Ezek mellett, ú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. 
 
 \begin{figure}[!ht]
 \centering
@@ -13,13 +13,13 @@ Az \ref{fig:docker-chart} ábrából látszik, hogy a Jmeter jobban teljesített
 \label{fig:docker-chart}
 \end{figure}
 
-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ímszá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.
 
-Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb, valamint teljes\'itm\'enye \'ujb\'ol felűlm\'ulja a limit\'alt hey-\'et. 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, valamint teljes\'itm\'enye \'ujb\'ol fel\"ulm\'ulja a limit\'alt hey-\'et. 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. 
+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 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. 
 
 \begin{figure}[!ht]
 \centering
@@ -31,18 +31,18 @@ Az \ref{fig:jmeter-for-otodik-chart} \'es \aref{fig:knative-for-negyedik-chart}
 \begin{figure}[!ht]
 \centering
 \includegraphics[width=120mm, keepaspectratio]{figures/knative-for-negyedik-chart.png}
-\caption{Echo t\'ipus\'u f\"uggv\'eny konstans terhel\'ese Hey eszk\"ozzel} 
+\caption{Echo t\'ipus\'u f\"uggv\'eny konstans terhel\'ese hey eszk\"ozzel} 
 \label{fig:knative-for-negyedik-chart}
 \end{figure}
 
 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 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. 
 
 \begin{figure}[!ht]
 \centering
 \includegraphics[width=120mm, keepaspectratio]{figures/hatodik-isprime-knative-for-chart.png}
-\caption{Pr\'imsz\'amol\'o f\"uggv\'eny konstans terhel\'ese Hey eszk\"ozzel} 
+\caption{Pr\'imsz\'amol\'o f\"uggv\'eny konstans terhel\'ese hey eszk\"ozzel} 
 \label{fig:hatodik-isprime-knative-for-chart}
 \end{figure}
 
@@ -55,9 +55,9 @@ Az \ref{fig:hatodik-isprime-knative-for-chart} \'es \aref{fig:jmeter-hatodik-py-
 
 \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.
+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.
+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 12 \'or\'an \'at 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.
 
 \begin{figure}[!ht]
 \centering
@@ -76,27 +76,27 @@ 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 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á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.
 
 \begin{figure}[!ht]
 \centering
 \includegraphics[width=120mm, keepaspectratio]{figures/hatodik-hello-knative-climb-chart.png}
-\caption{Echo t\'ipus\'u f\"uggv\'eny emelkedő terhel\'ese Hey eszk\"ozzel} 
+\caption{Echo t\'ipus\'u f\"uggv\'eny emelkedő terhel\'ese hey eszk\"ozzel} 
 \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 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
 \includegraphics[width=120mm, keepaspectratio]{figures/hatodik-isprime-knative-climb-chart.png}
-\caption{Pr\'imsz\'amol\'o f\"uggv\'eny emelkedő terhel\'ese Hey eszk\"ozzel} 
+\caption{Pr\'imsz\'amol\'o f\"uggv\'eny emelkedő terhel\'ese hey eszk\"ozzel} 
 \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. 
+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 Isitiot. 
 
 \begin{figure}[!ht]
 \centering
@@ -107,7 +107,7 @@ Mivel a Knative és Kubeless rendszerek másik Ingress Controllert használtak,
 
 \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. 
+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 60 másodperces átlagolása miatt. 
 
 \begin{figure}[!ht]
 \centering
@@ -116,7 +116,7 @@ Ahogy \aref{fig:kubeless-isprime} ábrán látszik, a Kubeless skálázódása t
 \label{fig:kubeless-isprime}
 \end{figure}
 
-Sajnos, a Kubeless esetében többször előfordult, hogy csak egy Podot hozott létre az egész mérés során. Ez nem függött attól, hogy mennyi ideig tartott a mérés. Miután véget ért a terhelés, rövid időn belül létre jött a következő Pod. Ennek okát próbáltam kideríteni, egyik hipotézisem az volt, hogy nincs elég cpu ideje a számítógépnek létrehozni a Podot, de ezt kézi megfigyeléseim során elvetettem. Másik probléma a Kubeless esetében, hogy az Nginx Ingress Controller minden beérkező kérésről naplóbejegyzést ír. Ennek következményeképp a Podja Evicted \'allapotba ker\"ul, mert túl sok tárterületet használ. Az Evicted \'allapot azt jelenti, hogy az adott Pod t\'ul sok erőforr\'ast haszn\'alt, ami miatt a Kubernetes rendszer le\'all\'itotta. A degrad\'al\'odott teljes\'itm\'eny, melyet ez esetben lehetett tapasztalni, \aref{fig:jmeter-kubeless-hello-hatodik-rps-chart} \'abr\'an l\'athat\'o.
+Sajnos a Kubeless esetében többször előfordult, hogy csak egy podot hozott létre az egész mérés során. Ez nem függött attól, hogy mennyi ideig tartott a mérés. Miután véget ért a terhelés, rövid időn belül létre jött a következő pod. Ennek okát próbáltam kideríteni - egyik hipotézisem az volt, hogy nincs elég CPU ideje a számítógépnek létrehozni a podot, de ezt kézi megfigyeléseim során elvetettem. Másik probléma a Kubeless esetében, hogy az Nginx Ingress Controller minden beérkező kérésről naplóbejegyzést ír. Ennek következményeképp a podja Evicted \'allapotba ker\"ul, mert túl sok tárterületet használ. Az Evicted \'allapot azt jelenti, hogy az adott pod t\'ul sok erőforr\'ast haszn\'alt, ami miatt a Kubernetes rendszer le\'all\'itotta. A degrad\'al\'odott teljes\'itm\'eny, melyet ez esetben lehetett tapasztalni, \aref{fig:jmeter-kubeless-hello-hatodik-rps-chart} \'abr\'an l\'athat\'o.
 
 \begin{figure}[!ht]
 \centering
@@ -125,11 +125,11 @@ Sajnos, a Kubeless esetében többször előfordult, hogy csak egy Podot hozott
 \label{fig:jmeter-kubeless-hello-hatodik-rps-chart}
 \end{figure}
 
-Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tökéletes. Egy lehetőség a konténerek kézi (vagy akár automatizált) naplójainak rotációja. Ez azért nem jó megoldás, mert nem csak a függvény podok kerülnek Evicted állapotba, hanem akár a network plugin által használt Pod, hiszen a monitorozó rendszer minden Podtól lekérdezi az adatait, valamint a Kubernetes minden Podot Evicted állapotba tesz, ha túl sok ephemeral storage-ot használ. Ennél létezik egyszerűbb megoldás, ami jobb lehetőségnek tűnik. Ez a Docker logrendszerének átkonfigurálása, hogy ne a konténer fájljai között, json formátumban naplózzon, hanem például használja a gazda gép journald rendszer szolgáltatását. Ez meg is oldotta ezt a problémát, viszont felvetett egy másikat. Bár a naplóbejegyzések már nem kerülnek a konténerek mellé, valahol a fájlrendszeren kerülnek tárolásra, ahol egy idő után ugyan tömörítésre kerülnek, de addig jelentős helyet foglalnak a mérésből és a monitorozásból adódó bejegyzések. Ennek eredményeként a Kubernetes worker node-okon DiskPreassure állapot léphet fel, amely azt jelenti, hogy az adott Node fájlrendszerén kevés a fennmaradt szabad hely. Ez a szabály vonatkozik a Node root partíciójára, valamint a Docker konténereket tároló partícióra is. Ekkor a Node-on lévő Podok kerülhetnek Evicted állapotba, a Kubernetes megpróbálja azokat újraindítani, viszont ez már új konténer létrehozását jelenti. Erre két megoldási lehetőség létezik. Vagy a problémás Node kubelet konfigurációját átállítjuk, hogy a DiskPreassure állapot később lépjen fel, ezzel viszont csak elnapoltuk a problémát. Másik lehetőség a naplófájlok gyorsabb rotációja, illetve a Docker konténerek külön partíción tárolása, de ez esetben csak lelassítottuk a problémát. Az igazi megoldás a kettő módszer ötvözése. Naplóbejegyzések mindenképpen generálódni fognak, ezt megakadályozni nem tudjuk és nem is érdekünk, hiszen bármi probléma adódik, a naplóbejegyzések jelentős segítséget nyújtanak a diagnózisban, valamint akár a probléma megoldásában is segíthetnek.
+Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tökéletes. Egy lehetőség a konténerek kézi (vagy akár automatizált) naplójainak rotációja. Ez azért nem jó megoldás, mert nem csak a függvény podok kerülnek Evicted állapotba, hanem akár a network plugin által használt pod is, hiszen a monitorozó rendszer minden podtól lekérdezi az adatait, valamint a Kubernetes minden podot Evicted állapotba tesz, ha túl sok ephemeral storage-ot használ. Ennél létezik egyszerűbb megoldás, ami jobb lehetőségnek tűnik. Ez a Docker logrendszerének átkonfigurálása, hogy ne a konténer fájljai között, JSON formátumban naplózzon, hanem például használja a gazdagép \textit{journald} rendszer szolgáltatását. Ez meg is oldotta ezt a problémát, viszont felvetett egy másikat. Bár a naplóbejegyzések már nem kerülnek a konténerek mellé, valahol a fájlrendszeren kerülnek tárolásra, ahol egy idő után ugyan tömörítésre kerülnek, de addig jelentős helyet foglalnak a mérésből és a monitorozásból adódó bejegyzések. Ennek eredményeként a Kubernetes Worker Node-okon DiskPreassure állapot léphet fel, amely azt jelenti, hogy az adott Node fájlrendszerén kevés a fennmaradt szabad hely. Ez a szabály vonatkozik a Node root partíciójára, valamint a Docker konténereket tároló partícióra is. Ekkor a Node-on lévő podok kerülhetnek Evicted állapotba. A Kubernetes megpróbálja azokat újraindítani, viszont ez már új konténer létrehozását jelenti. Erre két megoldási lehetőség létezik. Vagy a problémás Node kubelet konfigurációját átállítjuk, hogy a DiskPreassure állapot később lépjen fel, ezzel viszont csak elnapoltuk a problémát. Másik lehetőség a naplófájlok gyorsabb rotációja, illetve a Docker konténerek külön partíción tárolása, de ez esetben csak lelassítottuk a problémát. Az igazi megoldás a kettő módszer ötvözése. Naplóbejegyzések mindenképpen generálódni fognak, ezt megakadályozni nem tudjuk és nem is érdekünk, hiszen bármi probléma adódik, a naplóbejegyzések jelentős segítséget nyújtanak a diagnózisban, valamint akár a probléma megoldásában is segíthetnek.
 
-Annak érdekében, hogy a Knative-ba telepített függvények skálázódása az általuk nyújtott teljesítményben is meglátszódjon, szerettem volna limitálni egy-egy Pod teljesítményét. Erre viszont a Knative által létrehozott objektum típusok esetében nincs lehetőség. Emiatt úgy döntöttem, hogy a Knative által létrehozott Kubernetes Deployment objektumot módosítom, ott hozom létre a limiteket. Ez sikerült is, a függvény működött tovább, a megadott korlátozások érvénybe léptek. Viszont az elvárások nem teljesültek, a Podok létrejöttével nem emelkedett meg a függvény teljesítménye. A lenti diagrammon látszik, hogy a függvény végig ezer kérést volt képes kiszolgálni másodpercenként. 
+Annak érdekében, hogy a Knative-ba telepített függvények skálázódása az általuk nyújtott teljesítményben is meglátszódjon, szerettem volna limitálni egy-egy pod teljesítményét. Erre viszont a Knative által létrehozott objektum típusok esetében nincs lehetőség. Emiatt úgy döntöttem, hogy a Knative által létrehozott Kubernetes Deployment objektumot módosítom, ott hozom létre a limiteket. Ez sikerült, a függvény működött tovább, a megadott korlátozások érvénybe léptek. Viszont az elvárások nem teljesültek, a podok létrejöttével nem emelkedett meg a függvény teljesítménye. A lenti diagrammon látszik, hogy a függvény végig ezer kérést volt képes kiszolgálni másodpercenként. 
 
-Korábbi mérések során a prímszámoló függvény egy Python folyamatot használva nyolcszáz kérést szolgált ki másodpercenként. Tehát a mérés során létrejött öt Pod nagyjából négyezer kérést kellene kiszolgálnia másodpercenként az elvárásaink alapján. Ezzel szemben, ahogy \aref{fig:jmeter-pillanat-junky-chart} \'abr\'an l\'atszik, az egész mérés során olyan teljesítményt nyújt a függvény, melyet két Pod is ki tudna szolgálni. Emellett a ny\'ujtott teljes\'itm\'eny a szok\'asosn\'al instabilabb volt.
+Korábbi mérések során a prímszámoló függvény egy Python folyamatot használva nyolcszáz kérést szolgált ki másodpercenként. Tehát a mérés során létrejött öt pod nagyjából négyezer kérést kellene kiszolgálnia másodpercenként az elvárásaink alapján. Ezzel szemben, ahogy \aref{fig:jmeter-pillanat-junky-chart} \'abr\'an l\'atszik, az egész mérés során olyan teljesítményt nyújt a függvény, melyet két pod is ki tudna szolgálni. Emellett a ny\'ujtott teljes\'itm\'eny a szok\'asosn\'al instabilabb volt.
 
 \begin{figure}[!ht]
 \centering
@@ -140,9 +140,9 @@ Korábbi mérések során a prímszámoló függvény egy Python folyamatot hasz
 
 \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.
+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. Majd ú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áltak.
 
-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.
+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.
 
 \begin{figure}[!ht]
 \centering
@@ -151,7 +151,7 @@ Az \ref{fig:grafana-isprime-controllvsdata} ábrán látható, hogy a függvény
 \label{fig:grafana-isprime-controllvsdata}
 \end{figure}
 
-Látszik, hogy a Knative Serving komponense használja leginkább a processzort. A kubectl top parancsot használva azt is sikerült kideríteni, hogy pontosan az Activator nevű komponens miatt emelkedik ki a Knative processzorhasználata. A Knative Activator felel a metrik\'ak autoscaler fel\'e tov\'abb\'it\'as\'a\'ert, valamint inaktiv Revision-\"okh\"oz \'erkező k\'er\'esek bufferel\'es\'e\'ert. A Grafana által generált grafikonok egyikén megfigyelhető, hogy a pánik mód mikor kapcsolt be és meddig tartott. Ez a lenti grafikonon látszik. A pánik mód a specifikáltak szerint viselkedik, \aref{fig:grafana-isprime-controlplane-namespaces} ábrán az is látszik, miként alakult a Podok száma a mérés során.
+Látszik, hogy a Knative Serving komponense használja leginkább a processzort. A kubectl \textit{top} parancsot használva azt is sikerült kideríteni, hogy pontosan az Activator nevű komponens miatt emelkedik ki a Knative processzorhasználata. A Knative Activator felel a metrik\'ak Autoscaler fel\'e tov\'abb\'it\'as\'a\'ert, valamint inakt\'iv Revision-\"okh\"oz \'erkező k\'er\'esek bufferel\'es\'e\'ert. A Grafana által generált grafikonok egyikén megfigyelhető, hogy a pánik mód mikor kapcsolt be és meddig tartott. Ez a lenti grafikonon látszik. A pánik mód a specifikáltak szerint viselkedik, \aref{fig:grafana-isprime-controlplane-namespaces} ábrán az is látszik, miként alakult a podok száma a mérés során.
 
 \begin{figure}[!ht]
 \centering
@@ -160,7 +160,7 @@ Látszik, hogy a Knative Serving komponense használja leginkább a processzort.
 \label{fig:grafana-isprime-controlplane-namespaces}
 \end{figure}
 
-Az \ref{fig:grafana-isprime-panik} \'es \aref{fig:grafana-isprime-jmeter} \'abr\'akon l\'atszik, hogy a p\'anik m\'od sor\'an l\'etrej\"ottek r\"ovid idő alatt a Podok, majd ut\'ana v\'egig k\"ozel annyi sz\'am\'u Pod volt. Az is megfigyelhető, hogy b\'ar a hosztg\'ep nincs kihaszn\'alva, a f\"uggv\'eny teljes\'itm\'enye degrad\'al\'odott.
+Az \ref{fig:grafana-isprime-panik} \'es \aref{fig:grafana-isprime-jmeter} \'abr\'akon l\'atszik, hogy a p\'anik m\'od sor\'an l\'etrej\"ottek r\"ovid idő alatt a podok, majd ut\'ana v\'egig k\"ozel ugyanannyi sz\'am\'u pod volt. Az is megfigyelhető, hogy b\'ar a hosztg\'ep nincs kihaszn\'alva, a f\"uggv\'eny teljes\'itm\'enye degrad\'al\'odott.
 
 \begin{figure}[!ht]
 \centering
@@ -176,7 +176,7 @@ Az \ref{fig:grafana-isprime-panik} \'es \aref{fig:grafana-isprime-jmeter} \'abr\
 \label{fig:grafana-isprime-jmeter}
 \end{figure}
 
-A Knative rendszer sz\'amos m\'odon sz\'amontartja a f\"uggv\'enybe \'erkező konkurens k\'er\'esek sz\'am\'at. P\'eld\'aul, mint ahogy az \aref{fig:grafana-isprime-observedconcurrency} \'abr\'an l\'athat\'o, az Average Panic Concurrency egy r\"ovidebb idő alatt sz\'amolt \'atlag, mint ahogy a p\'anik sk\'al\'az\'ashoz sz\"uks\'eges. Az Average Concurrency egy sokkal lassabban v\'altoz\'o \'ert\'ek, ez az, ami az eddigi m\'er\'esek sor\'an ki lett nyerve az autoscaler napl\'of\'ajljaib\'ol. A Target Concurrency \'ert\'ek a YAML \'allom\'anyban be\'all\'itott \'ert\'ek. Az Excess Burst Capacity \'ert\'ek reprezent\'alja a k\"ul\"onbs\'eget a f\"uggv\'eny tartal\'ek kapacit\'asa - mennyi t\"obblet terhel\'est k\'epes a f\"uggv\'eny feldolgozni, mielőtt t\'ulterhelődik - \'es a be\'all\'itott c\'elkonkurencia k\"oz\"ott. Amennyiben ez a sz\'am negat\'iv, az Activator komponensen is \'atmennek a be\'erkező k\'er\'esek.
+A Knative rendszer sz\'amos m\'odon sz\'amontartja a f\"uggv\'enybe \'erkező konkurens k\'er\'esek sz\'am\'at. P\'eld\'aul, mint ahogy az \aref{fig:grafana-isprime-observedconcurrency} \'abr\'an l\'athat\'o, az Average Panic Concurrency egy r\"ovidebb idő alatt sz\'amolt \'atlag, mint, ami a p\'anik sk\'al\'az\'ashoz sz\"uks\'eges. Az Average Concurrency egy sokkal lassabban v\'altoz\'o \'ert\'ek, ez az, ami az eddigi m\'er\'esek sor\'an ki lett nyerve az Autoscaler napl\'of\'ajljaib\'ol. A Target Concurrency \'ert\'ek a YAML \'allom\'anyban be\'all\'itott \'ert\'ek. Az Excess Burst Capacity \'ert\'ek reprezent\'alja a k\"ul\"onbs\'eget a f\"uggv\'eny tartal\'ek kapacit\'asa - mennyi t\"obblet terhel\'est k\'epes a f\"uggv\'eny feldolgozni, mielőtt t\'ulterhelődik - \'es a be\'all\'itott c\'elkonkurencia k\"oz\"ott. Amennyiben ez a sz\'am negat\'iv, az Activator komponensen is \'atmennek a be\'erkező k\'er\'esek.
 
 \begin{figure}[!ht]
 \centering