diff --git a/src/content/preparation.tex b/src/content/preparation.tex
index 9730783..b7fee6b 100644
--- a/src/content/preparation.tex
+++ b/src/content/preparation.tex
@@ -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.
 
 \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.
 
@@ -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.
 
 \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.