\chapter{M\'er\'esi eredm\'enyek ismertet\'ese}

\section{Elk\'esz\'itett f\"uggv\'enyek teljes\'itm\'eny\'enek m\'er\'ese Dockerben telep\'itve}

Mielőtt elkezdtem a Knative és Kubeless rendszerek mérését, annak érdekében, hogy a mérőeszközök, illetve a Knative-hoz készített függvények teljesítményét kimérjem, mindkét 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 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
\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}

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\"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 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
\includegraphics[width=120mm, keepaspectratio]{figures/jmeter-for-otodik-chart.png}
\caption{Echo t\'ipus\'u f\"uggv\'eny konstans terhel\'ese Jmeter eszk\"ozzel} 
\label{fig:jmeter-for-otodik-chart}
\end{figure}

\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} 
\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. 

\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} 
\label{fig:hatodik-isprime-knative-for-chart}
\end{figure}

\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/jmeter-hatodik-py-chart.png}
\caption{Pr\'imsz\'amol\'o f\"uggv\'eny konstans terhel\'ese Jmeter eszk\"ozzel} 
\label{fig:jmeter-hatodik-py-chart}
\end{figure}

\section{F\"uggv\'enyek v\'alaszidej\'enek alakul\'asa cold \'es hotstart esetekben}

Ez ut\'an m\'ertem ki, mennyi a k\"ul\"onbs\'eg a f\"uggv\'eny v\'alaszidej\'eben az esetben, hogy null\'ara van sk\'al\'azva, vagy sem. A tapasztalat az volt, hogy 2-3 m\'asodpercig tart a pod l\'etrehoz\'asa, a v\'alaszidő ennyivel n\"ovekedett meg az echo t\'ipus\'u f\"uggv\'eny eset\'eben. A bevezetett, nagyobb sz\'am\'it\'asig\'enyű f\"uggv\'eny e m\'er\'es sor\'an hasonl\'oan viselkedett, viszont \'atlagosan egy m\'asodperccel tov\'abb tartott a pod indul\'asa. Ez az\'ert \'erdekes, mert a k\'et f\"uggv\'eny m\'asik futtat\'ok\"ornyezettel rendelkezik, tipikusan a Python interpreter elind\'it\'asa 1-2 m\'asodpercet vesz ig\'enybe, ez megmagyar\'azza, mi\'ert tapasztalhat\'o ez a k\"ul\"onbs\'eg - amely j\'ol megfigyelhető \aref{fig:go-start-chart} \'es \aref{fig:py-start-chart} \'abr\'akon - a k\'et f\"uggv\'eny k\"oz\"ott.

Az \ref{fig:go-start-chart} \'abr\'an l\'athat\'o az echo t\'ipus\'u f\"uggv\'eny v\'alaszidej\'enek alakul\'asa. A m\'er\'est k\"or\"ulbel\"ul 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
\includegraphics[width=120mm, keepaspectratio]{figures/go-start.png}
\caption{Echo t\'ipus\'u f\"uggv\'eny v\'alaszideje Cold \'es Hotstart esetekben} 
\label{fig:go-start-chart}
\end{figure}


\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/py-start.png}
\caption{Pr\'imsz\'amol\'o f\"uggv\'eny v\'alaszideje Cold \'es Hotstart esetekben} 
\label{fig:py-start-chart}
\end{figure}

\section{Knative rendszerbe telep\'itett f\"uggv\'enyek sk\'al\'az\'od\'asa n\"ovekedő terhel\'es alatt}

Az \ref{fig:hatodik-hello-knative-climb-chart} ábrán látható az echo típusú függvényre egyre növekvő terhelés, valamint a Knative Autoscaler rendszer e mérés alatti belső állapota. A terhelés növelését a hey mérőeszközben egyre több connection objektum haszná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} 
\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.

\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} 
\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 Isitiot. 

\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}

\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 60 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}

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
\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 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, 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.

\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}

\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. 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.

\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-controllvsdata.png}
\caption{Processzorhaszn\'alat ar\'any\'anak alakul\'asa pr\'imsz\'amol\'o f\"uggv\'eny terhel\'ese sor\'an} 
\label{fig:grafana-isprime-controllvsdata}
\end{figure}

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
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-controlplane-namespaces.png}
\caption{Ir\'any\'it\'asi rendszerek processzorhaszn\'alat\'anak alakul\'asa pr\'imsz\'am\'aol\'o f\"uggv\'eny terhel\'ese sor\'an} 
\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 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
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-panik.png}
\caption{Knative p\'anik \'allapot\'anak alakul\'asa pr\'imsz\'amol\'o f\"uggv\'eny terhel\'ese sor\'an} 
\label{fig:grafana-isprime-panik}
\end{figure}

\begin{figure}[!ht]
\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, 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
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-observedconcurrency.png}
\caption{Knative \'altal sz\'amolt konkurencia \'ert\'ekek} 
\label{fig:grafana-isprime-observedconcurrency}
\end{figure}

Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését. Az \ref{fig:grafana-hello-controllvsdata} \'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.

\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-hello-controllvsdata.png}
\caption{Processzorhaszn\'alat ar\'any\'anak alakul\'asa echo t\'ipus\'u f\"uggv\'eny terhel\'ese sor\'an} 
\label{fig:grafana-hello-controllvsdata}
\end{figure}
