tormakris/knative-report-latex
1
0
Fork 0
Code Issues Pull Requests Releases Activity

grammar fixing in progress

Browse Source
This commit is contained in:
Torma Kristóf
2019-12-12 01:40:21 +01:00
parent 61510d2f87
commit 8b3d4de355
7 changed files with 68 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/content/results.tex
View File

@@ -55,7 +55,7 @@ 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.
@@ -76,7 +76,7 @@ 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 hat másodperces időtartam alatt.
\begin{figure}[!ht]
\centering
@@ -142,7 +142,7 @@ Korábbi mérések során a prímszámoló függvény egy Python folyamatot hasz
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.
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