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

cpu

Browse Source
This commit is contained in:
Torma Kristóf 2019-12-12 18:11:31 +01:00
parent eaaf6101a6
commit 774a647225
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/content/preparation.tex
View File

@ -60,7 +60,7 @@ A végső szempont a megfelelő dokumentáció elérhetősége. Hiába felel meg
A megfelelő mérési eszköz kiválasztásához számos eszközt megvizsgáltam, melyeket a k\"ovetkező pontokban fejtek ki. A megfelelő mérési eszköz kiválasztásához számos eszközt megvizsgáltam, melyeket a k\"ovetkező pontokban fejtek ki.
\subsection{Wrk} \subsection{Wrk}
A wrk egy C-ben írt, nyílt forráskódú HTTP teljesítménymérő szoftver. Többszálú designjának köszönhetően nagy sebességgel képes generálni a kéréseket. A használt kapcsolat objektumok és szálak száma parancssori kapcsoló segítségével beállítható, valamint működésének bizonyos aspektusai Lua szkriptnyelven testreszabhatók. Egyetlen hátránya, hogy bár a kimeneti formátumot Lua-ban írt szkript segítségével testre lehet szabni, nincs lehetőség minden kérés vagy bizonyos időközönként átlagolt részeredmény exportálására. Mivel a wrk az általam vizsgált megoldások közül az egyik legrégebb óta fejlesztett, a hozzá elérhető dokumentáció kitér a gyakran előforduló problémákra, valamint a szkriptelést megkönnyítik a fejlesztők által előre elkészített példák. A wrk a mérés végeztével egyszer menti a másodpercenkénti átlagos kérések számát, amire érkezett valamilyen válasz, valamint egyebek mellett az átlagos k\'er\'es r\'at\'at, amivel a válasz megérkezett. A wrk egy C-ben írt, nyílt forráskódú HTTP teljesítménymérő szoftver. Többszálú designjának köszönhetően nagy sebességgel képes generálni a kéréseket. A használt kapcsolat objektumok és szálak száma parancssori kapcsoló segítségével beállítható, valamint működésének bizonyos aspektusai Lua szkriptnyelven testreszabhatók. Egyetlen hátránya, hogy bár a kimeneti formátumot Lua-ban írt szkript segítségével testre lehet szabni, nincs lehetőség minden kérés vagy bizonyos időközönként átlagolt részeredmény exportálására. Mivel a wrk az általam vizsgált megoldások közül az egyik legrégebb óta fejlesztett, a hozzá elérhető dokumentáció kitér a gyakran előforduló problémákra, valamint a szkriptelést megkönnyítik a fejlesztők által előre elkészített példák. A wrk a mérés végeztével egyszer menti a másodpercenkénti átlagos kérések számát, amire érkezett valamilyen válasz, valamint egyebek mellett az átlagos k\'er\'esr\'at\'at, amivel a válasz megérkezett.
Emiatt a wrk nem volt alkalmas a mérések elvégzésére. Emiatt a wrk nem volt alkalmas a mérések elvégzésére.
@ -80,7 +80,7 @@ Az Apache Jmeter vagy Jmeter egy Java 8-as verziójában íródott, nyílt forr
A Jmeter igen elterjedt szoftver, viszont kifejezetten bonyolult, szerencsére a hozzá elérhető dokumentáció az összes általam vizsgált eszköz közül a legrészletesebb volt. Mivel a Jmeter működése eltér a hey-től, valamint a kritériumoknak megfelel, úgy döntöttem a méréseket mindkét eszközzel elvégzem. A Jmeter igen elterjedt szoftver, viszont kifejezetten bonyolult, szerencsére a hozzá elérhető dokumentáció az összes általam vizsgált eszköz közül a legrészletesebb volt. Mivel a Jmeter működése eltér a hey-től, valamint a kritériumoknak megfelel, úgy döntöttem a méréseket mindkét eszközzel elvégzem.
\section{M\'er\'esek automatiz\'al\'asa} \section{M\'er\'esek automatiz\'al\'asa}
A mérőeszközök kiválasztása után magukat a méréseket dolgozhattam ki. Az egyértelmű volt, hogy konstans terhelésű mérést mindenképpen kell végezzek. Kubeless esetén mivel skálázása csak a cpu terheléstől függ, a skálázás megfigyelésére az ilyen típusú mérések elégségesek lehetnek. Ezzel szemben a Knative konkurencia alapú skálázásának megfigyelésére a bemeneti oldali konkurens kérések folyamatos növelése az előző típusú mérés mellett érdekesnek bizonyulhat. A mérőeszközök kiválasztása után magukat a méréseket dolgozhattam ki. Az egyértelmű volt, hogy konstans terhelésű mérést mindenképpen kell végezzek. Kubeless esetén mivel skálázása csak a CPU terheléstől függ, a skálázás megfigyelésére az ilyen típusú mérések elégségesek lehetnek. Ezzel szemben a Knative konkurencia alapú skálázásának megfigyelésére a bemeneti oldali konkurens kérések folyamatos növelése az előző típusú mérés mellett érdekesnek bizonyulhat.
Mivel a méréseket nem egyszerre végeztem, valamint a mérések elvégzéséhez a hey esetében a megfelelő parancssori kapcsolók lánca hosszú, szükségét láttam annak, hogy legalább a hey esetében egy Bash szkript segítségével automatizáljam a mérések elvégzését. A Jmeter esetében erre nincs szükség, hála az előre elkészíthető mérési terveknek. Mivel a méréseket nem egyszerre végeztem, valamint a mérések elvégzéséhez a hey esetében a megfelelő parancssori kapcsolók lánca hosszú, szükségét láttam annak, hogy legalább a hey esetében egy Bash szkript segítségével automatizáljam a mérések elvégzését. A Jmeter esetében erre nincs szükség, hála az előre elkészíthető mérési terveknek.