all charts added

src/.kile/thesis.kilepr.gui

@@ -216,16 +216,16 @@ TextFolding=[]
 ViMarks=.,116,0,[,116,0,],116,0
 
 [view-settings,view=0,item:content/results.tex]
-CursorColumn=888
+CursorColumn=19
-CursorLine=91
+CursorLine=112
 Dynamic Word Wrap=false
 JumpList=
 TextFolding=[]
-ViMarks=.,91,887,[,91,876,],91,887
+ViMarks=.,112,0,[,112,0,],112,0
 
 [view-settings,view=0,item:content/theory.tex]
-CursorColumn=374
+CursorColumn=0
-CursorLine=122
+CursorLine=38
 Dynamic Word Wrap=false
 JumpList=
 TextFolding=[]

src/content/closing.tex

@@ -13,6 +13,3 @@ Az elkészített Python programok és bash szkriptek felhasználhatók akár a K
 
 \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.
-
-%TODO remove
-Ez csak az\'ert van itt, hogy leforduljon ez a fos: \cite{Jeney}

src/content/results.tex

@@ -1,71 +1,112 @@
 \chapter{M\'er\'esi eredm\'enyek ismertet\'ese}
 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. 
 
-%TODO
+Az \ref{fig:docker-chart} ábrából látszik, hogy a várakozásokkal ellentétben a Jmeter jobban teljesített, mint a hey. Ez azért van, mert a hey-re megszabtam connection objektumomként ötszáz kérés per másodperces korlátot. Erre a számra úgy jutottam, hogy a hey által használt connection objektumok számát egyre állítottam. Ez esetben a generált kérések száma másodpercenként 510 és 530 között ingadozott, viszont stabilan mindig 500 felett volt. A generált forgalom stabilizálása érdekében az 500-nál húztam meg a határt, melynek szükségességét a korábbi tapasztalatok alapján éreztem, ugyanis a hey teljesítménye megfigyeléseim szerint instabil, mikor nagy sebességgel kell generálja a kéréseket. Továbbá, úgy ítéltem, hogy két különbözően viselkedő mérőeszköz többet fed fel a skálázódási mechanizmusokról. 
-<jmeter és hey hello docker>
 
-%TODO
+\begin{figure}[!ht]
-<jmeter és hey isprime docker> 
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/docker-chart.png}
+\caption{Docker kont\'enerben fut\'o f\"uggv\'enyek teljes\'itm\'eny\'enek m\'er\'ese } 
+\label{fig:docker-chart}
+\end{figure}
 
-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á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á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 Coldstart
 
 É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
+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. 
-<jmeter-for-otodik> 
 
-%TODO
+\begin{figure}[!ht]
-<knative-for-negyedik> 
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/jmeter-for-otodik-chart.png}
+\caption{Konstans terhel\'ese echo t\'ipus\'u f\"uggv\'enynek Jmeter eszk\"ozzel} 
+\label{fig:jmeter-for-otodik-chart}
+\end{figure}
 
-A fenti ábrákon látható a Knative-ba telepített echo típusú függvény skálázódása. A kettő közül először az alsó mérést végeztem el, ahol a hey instabil viselkedése szintén megfigyelhető. A mérés körülbelül felénél látható megemelkedett ráta konzisztensen megismételhető volt több, független Kubernetes klaszteren is. Az ábrák elején jól megfigyelhető a Knative pánik skálázása, amely gyorsan létrehoz öt Podot, majd a hatvan másodperces panic windows lejárta után a már nem szükséges podokat leállítja. Az ezután a Podok számában megfigyelhető hiszterézis a Jmeteres ábrán és egyéb Jmeteres mérések során nem volt tapasztalható. Ez betudható annak, hogy az ObservedStableConcurrency érték a döntési határértéken van. Szintén megfigyelhető, hogy a Podok kiszámításának korábban ismertetett formulája úgy tűnik nem volt helyes. Ez nem helyes következtetés, ugyanis a hey ábrán látható három, valamint a Jmeter ábrán látható kettő kiszámított Podszámhoz hozzáadódik az egy mindig létező Pod. Az ObservedStableConcurrency érték esése a Jmeter ábra esetén is látható, amire a Podok számának csökkentésével reagál a rendszer. Érdekes, hogy itt mind a Podok száma, mint az ObservedStableConcurrency sokkal stabilabbak, cserébe alacsonyabbak. Szintén különbség, hogy a hey esetében a mérés elején tapasztalható alacsony teljesítményű időszak időben hasonló, viszont nincs benne ugrás. Mindkét ábrán látszik, hogy az ObservedStableConcurrency érték mozgó átlag, emiatt lassan változik. Ennek következménye, hogy a terhelés megszűnése után nem szűnnek meg a létrehozott Podok. 
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/knative-for-negyedik-chart.png}
+\caption{Konstans terhel\'ese echo t\'ipus\'u f\"uggv\'enynek 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. 
 
-%TODO
+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. 
-<hatodik-isprime-knative-for> 
 
-%TODO
+\begin{figure}[!ht]
-<jmeter-hatodik-py> 
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/hatodik-isprime-knative-for-chart.png}
+\caption{Konstans terhel\'ese pr\'imsz\'amol\'o f\"uggv\'enynek Hey eszk\"ozzel} 
+\label{fig:hatodik-isprime-knative-for-chart}
+\end{figure}
 
-A fenn látható két ábrán 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/jmeter-hatodik-py-chart.png}
+\caption{Konstans terhel\'ese pr\'imsz\'amol\'o f\"uggv\'enynek Jmeter eszk\"ozzel} 
+\label{fig:jmeter-hatodik-py-chart}
+\end{figure}
 
-%TODO
+Az \ref{fig:hatodik-hello-knative-climb-chart} ábrán látható az echo típusú függvényre egyre növekvő terhelés, valamint a Knative Autoscaler rendszer e mérés alatti belső állapota. A terhelés növelését a hey mérőeszközben egyre több connection objektum használta által értem el. Jól látszik, hogy az ObservedStableConcurrency egy lassan változó érték, a mérés végére töredékét érte el annak az értéknek, amit az egyenletes terhelésű mérések során elért. Szintén látható a Podok számából, hogy pánik állapotot sem váltott ki a mérés. Erre nem is lehetett számítani, hiszen a használt konkurencia érték sosem növekedett duplájára hat másodperces időtartam alatt.  
-<hatodik-hello-knative-climb> 
 
-A fenti ábrán látható az echo típusú függvényre egyre növekvő terhelés, valamint a Knative Autoscaler rendszer e mérés alatti belső állapota. A terhelés növelését a hey mérőeszközben egyre több connection objektum használta által értem el. Jól látszik, hogy az ObservedStableConcurrency egy lassan változó érték, a mérés végére töredékét érte el annak az értéknek, amit az egyenletes terhelésű mérések során elért. Szintén látható a Podok számából, hogy pánik állapotot sem váltott ki a mérés. Erre nem is lehetett számítani, hiszen a használt konkurencia érték sosem növekedett duplájára hat másodperces időtartam alatt.  
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/hatodik-hello-knative-climb-chart.png}
+\caption{Emelkedő terhel\'ese echo t\'ipus\'u f\"uggv\'enynek Hey eszk\"ozzel} 
+\label{fig:hatodik-hello-knative-climb-chart}
+\end{figure}
 
-%TODO
+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ő, hogy ez esetben nem j\"ott l\'etre m\'asodik Pod.
-<hatodik-isprime-knative-climb> 
 
-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, de a csalódnom kellett, ugyanis a gyengébb csúcsteljesítményen kívül egyéb különbség nem figyelhető meg a két függvény típusa között. 
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/hatodik-isprime-knative-climb-chart.png}
+\caption{Emelkedő terhel\'ese pr\'imsz\'amol\'o f\"uggv\'enynek Hey eszk\"ozzel} 
+\label{fig:hatodik-isprime-knative-climb-chart}
+\end{figure}
 
-%TODO
+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. 
-<istio és nginx egy ábrán> 
 
-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. A fenti ábrákon látható teljesítmény az adott Ingress Controllerek által elérhető legjobb teljesítmény. A Kubeless által használt Nginx Ingress Controller teljesítménye majdnem négyszeresen meghaladja a Knative által használt Isitio. 
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/istio-nginx-chart.png}
+\caption{Istio \'es Nginx Ingress Controllerek teljes\'itm\'eny\'enek m\'er\'ese Jmeter eszk\"ozzel} 
+\label{fig:istio-nginx-chart}
+\end{figure}
 
-%TODO
+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. 
-<valami kubeless cucc kell ide> 
 
-Ahogy az az ábrán látszik, a Kubeless skálázódása teljesen máshogy működik. Ez esetben a kötelezően meghatározott cpu használati limit miatt a skálázódáson a teljesítményben is érzékelhető a több Pod használata. Szintén látszik, hogy a csúcsteljesítmény, amit elért magasabb, mint a Knative esetében. Cserébe, viszont a skálázódás lassabb, a Horizontal Pod Autoscaler hatvan másodperces átlagolása miatt. 
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/kubeless-isprime.png}
+\caption{Kubeless rendszerbe telep\'itett pr\'imsz\'amol\'o f\"uggv\'eny sk\'al\'az\'od\'asa} 
+\label{fig:kubeless-isprime}
+\end{figure}
 
-%TODO
+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. 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.
-<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.
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/jmeter-kubeless-hello-hatodik-rps-chart.png}
+\caption{Kubeless rendszerbe telep\'itett echo t\'ipus\'u f\"uggv\'eny hib\'as műk\"od\'ese} 
+\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.
 
 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
+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.
-<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.
+\begin{figure}[!ht]
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/jmeter-pillanat-junky-chart.png}
+\caption{Processzorhaszn\'alatban limit\'alt pr\'imsz\'amol\'o, Knative rendszerbe telep\'itett f\"uggv\'eny sk\'al\'az\'od\'asa} 
+\label{fig:jmeter-pillanat-junky-chart}
+\end{figure}
 
 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.
 
@@ -87,7 +128,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{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 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.
 
 \begin{figure}[!ht]
 \centering
@@ -96,8 +137,12 @@ Az \ref{fig:grafana-isprime-panik} \'es \aref{grafana-isprime-jmeter} \'abr\'ako
 \label{fig:grafana-isprime-panik}
 \end{figure}
 
-%TODO
+\begin{figure}[!ht]
-<grafana-isprime-jmeter>
+\centering
+\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-jmeter-chart.png}
+\caption{Pr\'imsz\'amol\'o f\"uggv\'eny teljes\'itm\'enye Monitoring rendszer mellett} 
+\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.