diff --git a/src/content/preparation.tex b/src/content/preparation.tex
index fa6ecfd..c1504f1 100644
--- a/src/content/preparation.tex
+++ b/src/content/preparation.tex
@@ -100,7 +100,7 @@ A folyamatos terhel\'est gener\'al\'o m\'er\'es \aref{code:bash-banchmark-for} f
 Mint az \aref{code:bash-banchmark-climb} kódrészleten látszik, a növekvő terhelésű mérés implementációja igen hasonló az egyenletes terhelésűhöz. A hey működését kihasználva, a –rps kapcsoló segítségével beállított limit nem változik a mérés során, csupán a connection objektumok száma emelkedik.
 
 \section{Null\'ara sk\'al\'az\'as eset\'eben v\'alaszidő m\'er\'ese}
-Teljesen m\'ashogy kell m\'erni azt, hogy mik\'ent alakul a v\'alaszideje a f\"uggv\'enynek olyan esetekben, hogy \'eppen null\'ara sk\'al\'azta a Knative rendszer a podj\'at vagy a k\'er\'es be\'erkez\'esekor m\'ar l\'etezett a podja. Erre az esetre olyan m\'er\'est alak\'itottam ki, amely elk\"uld egy k\'er\'est a f\"uggv\'eny fel\'e, egy \'allom\'anyba r\"ogz\'iti a v\'alaszidőt, majd k\"ozvetlen ezut\'an ism\'etelten k\'er\'est k\"uld \'es egy m\'asik \'allom\'anyba r\"ogz\'iti ezt a v\'alaszidőt. Az \'altalam k\'esz\'itett szkript pontosan k\'et percet v\'ar. Az\'ert ennyi időt, mert tapasztalataim alapj\'an k\"or\"ulbel\"ul m\'asf\'el percig tartott a f\"uggv\'enyek podjainak termin\'al\'asa, a v\'arakoz\'asnak pedig enn\'el nagyobb időt szerettem volna be\'all\'itani arra az esetre, amikor enn\'el is tov\'abb tart a le\'all\'as. A m\'er\'est egy Bash szkript seg\'its\'eg\'evel lehet elk\'esz\'iteni, ami addig fut, am\'ig a felhaszn\'al\'o le nem \'all\'itja. Bőv\'iteni egyszerűen lehet, ugyanis a m\'erendő f\"uggv\'enyek egy list\'aban vannak felsorolva, minden v\'arakoz\'as előtt az ott felsorolt f\"uggv\'enyekre megt\"ort\'enik a v\'alaszidők m\'er\'ese.
+Teljesen m\'ashogy kell m\'erni azt, hogy mik\'ent alakul a v\'alaszideje a f\"uggv\'enynek olyan esetekben, hogy \'eppen null\'ara sk\'al\'azta a Knative rendszer a podj\'at vagy a k\'er\'es be\'erkez\'esekor m\'ar l\'etezett a podja. Erre az esetre olyan m\'er\'est alak\'itottam ki, amely elk\"uld egy k\'er\'est a f\"uggv\'eny fel\'e, egy \'allom\'anyba r\"ogz\'iti a v\'alaszidőt, majd ism\'etelten k\'er\'est k\"uld \'es egy m\'asik \'allom\'anyba r\"ogz\'iti ezt a v\'alaszidőt is. Az \'altalam k\'esz\'itett szkript pontosan k\'et percet v\'ar. Az\'ert ennyi időt, mert tapasztalataim alapj\'an k\"or\"ulbel\"ul m\'asf\'el percig tartott a f\"uggv\'enyek podjainak termin\'al\'asa, a v\'arakoz\'asnak pedig enn\'el nagyobb időt szerettem volna be\'all\'itani arra az esetre, amikor enn\'el is tov\'abb tart a le\'all\'as. A m\'er\'est egy Bash szkript seg\'its\'eg\'evel lehet elk\'esz\'iteni, ami addig fut, am\'ig a felhaszn\'al\'o le nem \'all\'itja. Bőv\'iteni egyszerűen lehet, ugyanis a m\'erendő f\"uggv\'enyek egy list\'aban vannak felsorolva, minden v\'arakoz\'as előtt az ott felsorolt f\"uggv\'enyekre megt\"ort\'enik a v\'alaszidők m\'er\'ese.
 
 \section{M\'er\'esi eredm\'enyek automatiz\'alt elemz\'ese}
 Egy mérés eredményeként a mérés típusától függően akár több, nagy méretű csv állomány keletkezik. Ezen fájlok feldolgozása függ attól, hogy azt a Jmeter vagy a hey generálta. A fájlok kézi feldolgozása nyilvánvalóan lehetetlen. Az is előfordulhat, hogy már a korábban feldolgozott méréseket egy új szempontból is fel kell dolgozni. Ez elő is fordult, ugyanis a program első verziója még nem volt képes az észlelt késleltetés feldolgozására. Szerencsére a Python programnyelv ilyen feladatok elvégzésére kiváló választás.