text done for real

src/content/results.tex

@@ -62,24 +62,36 @@ Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tö
 
 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>
 
 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 hogyan alakul egymáshoz képest. 
-
-<grafana-isprime-cpu>
+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.
 
+%TODO
 <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.
+A fenti á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.
 
+%TODO
 <grafana-isprime-controlplane-namespaces>
 
-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.
+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-podszam>
+%TODO
+<grafana-isprime-jmeter>
 
-Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését.
+A fenti k\'et \'abr\'an 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.
+
+<grafana-isprime-observedconcurrency>
+
+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 a fenti \'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.
+
+Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését. A lenti \'abr\'an megfigyelhető, hogy ez esetben a Control Plane processzorhaszn\'alata t\"obb volt, mint a Data Plane-\'e. A m\'er\'es sor\'an ez esetben is romlott a monitoring rendszer telep\'it\'ese ut\'an.
+
+%TODO
+<grafana-hello-controllvsdata>