some todo done

src/content/results.tex

@@ -9,25 +9,11 @@ Mielőtt elkezdtem a Knative és Kubeless rendszerek mérését, annak érdekéb
 
 A két ábrából látszik, hogy a várakozásokkal ellentétben a Jmeter jobban teljesített, mint a hey. Ez azért van, mert a hey-re megszabtam connection objektumomként ötszáz kérés per másodperces korlátot. Erre a számra úgy jutottam, hogy a hey által használt connection objektumok számát egyre állítottam. Ez esetben a generált kérések száma másodpercenként 510 és 530 között ingadozott, viszont stabilan mindig 500 felett volt. A generált forgalom stabilizálása érdekében az 500-nál húztam meg a határt, melynek szükségességét a korábbi tapasztalatok alapján éreztem, ugyanis a hey teljesítménye megfigyeléseim szerint instabil, mikor nagy sebességgel kell generálja a kéréseket. Továbbá, úgy ítéltem, hogy két különbözően viselkedő mérőeszköz többet fed fel a skálázódási mechanizmusokról. 
 
-Az ábrákró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ített függvényeket önmagukban nem lehet kipróbálni. 
+Az ábrákról szintén látszik, hogy a prím számoló függvény teljesítménye alulmarad a kis számításigényű függvényhez képest. Ez az előzetes várakozások szerint alakult. Mivel a Kubeless egy teljes Function as a Service rendszer, az oda telep\'it\'esre sz\'ant f\"uggv\'enyeket csak a rendszerbe telep\'itve lehet futtatni.
 
-%TODO
-<knative-elso-coldstart és latency> 
+%TODO Coldstart
 
-A fent látható ábra az első mérés volt, amit a Knative-ba telepített echo típusú függvényen végeztem. Az eredménye kifejezetten meglepett, ugyanis a két mérés között nem csak szignifikánsan nagy a különbség, de a hey harminc másodperces futásai közül az elsőben kifejezetten nagy a feldolgozott kérések rátája, csak utána csökken le ezer körüli értékre. Később a késleltetési értékeket megtekintve ahogy sejtettem, hogy az első harminc másodpercben a kérések nem értek el a Podig, ugyanis itt a késleltetés kifejezetten alacsony volt. 
-
-%TODO
-<hatodik-hello-knative-cold részlet> 
-
-A korábbi mérést megismételve, hosszabb ideig futtatva a mért teljesítmény ingadozása megmarad, viszont az ezerig történő beesés nem tapasztalható. 
-
-%TODO
-<jmeter-hatodik-go-cold> 
-
-%TODO
-<jmeter-hatodik-go-hot> 
-
-A fenti két ábrán látható, hogy az nincs kihatással a függvény teljesítményére, hogy létezett-e a mérés indítása előtt. Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb. Igaz, hogy ez esetben nincs szükség a mérést fél perces szegmensekre bontani. Különösen furcsa a hey viselkedése, ugyanis a hiszterézis akkor nem volt megfigyelhető, ha a függvényt közvetlen Dockerben futtattam. Emiatt használatát nem vetettem el, de az általa mért feldolgozott kérési rátát fenntartással kezeltem. 
+Érdekes jelenség, hogy a Jmeter által mért teljesítmény sokkal stabilabb. Igaz, hogy ez esetben nincs szükség a mérést fél perces szegmensekre bontani. Különösen furcsa a hey viselkedése, ugyanis a hiszterézis akkor nem volt megfigyelhető, ha a függvényt közvetlen Dockerben futtattam. Emiatt használatát nem vetettem el, de az általa mért feldolgozott kérési rátát fenntartással kezeltem. 
 
 %TODO
 <jmeter-for-otodik> 
@@ -70,36 +56,30 @@ Ahogy az az ábrán látszik, a Kubeless skálázódása teljesen máshogy műk
 %TODO
 <jmeter-kubeless-hello-go-hatodik-rps> 
 
-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 Evictelődik, mert túl sok tárterületet használ. 
+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 Evictelődik, mert túl sok tárterületet használ.
 
-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 Pod-tól lekérdezi az adatait, valamint a Kubernetes minden Pod-ot 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ő Pod-ok 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, 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.
 
-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 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. 
 
-%TODO
-<jmeter-pillanat-junky> 
+<jmeter-pillanat-junky>
 
-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 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. 
+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 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.
 
-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. Az első ábrán a Podok CPU használata látható. Érdekes, hogy a Workeren elérhető húsz magból összesen hetet sem használnak. A második ábrán látható, hogy a függvényt kiszolgáló Podok és a Knative rendszer processzorhasználata, hogy alakul egymáshoz képest.  
+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. Az első ábrán a Podok CPU használata látható. Érdekes, hogy a Workeren elérhető húsz magból összesen hetet sem használnak. A második ábrán látható, hogy a függvényt kiszolgáló Podok és a Knative rendszer processzorhasználata hogyan alakul egymáshoz képest. 
 
-%TODO
-<grafana-isprime-cpu> 
+<grafana-isprime-cpu>
 
-%TODO
-<grafana-isprime-controllvsdata> 
+<grafana-isprime-controllvsdata>
 
-É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. 
+É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.
 
-%TODO
-<grafana-isprime-controlplane-namespaces> 
+<grafana-isprime-controlplane-namespaces>
 
-Látszik, hogy leginkább 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 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, az xy á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 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, az xy ábrán az is látszik, miként alakult a Podok száma a mérés során.
 
-%TODO
-<grafana-isprime-panik> 
+<grafana-isprime-panik>
 
-%TODO
-<grafana-isprime-podszam> 
+<grafana-isprime-podszam>
 
-Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését. 
+Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését.