A lecke végére meg tudod különböztetni a szerveroldali és a felhasználói oldalon mért időt, el tudod magyarázni, miért romlik a válaszidő nemlineárisan a kapacitás közelében, és tudod, miért percentilisekben gondolkodunk átlag helyett.
Miért nem elég egyetlen szerveroldali idő?
A rendszer teljesítményét nem lehet egyetlen szerveroldali idővel leírni. A hálózat, a szerver, a letöltött erőforrások és a böngésző munkája együtt határozza meg, mikor tud a felhasználó értelmesen cselekedni (9.4). A lecke a szerveroldali kérdést mélyíti el: mi történik a válaszidővel, amikor több felhasználó érkezik egyszerre?
Három külön kérdésre érdemes gondolni: milyen gyorsan válaszol a szerver; milyen gyorsan jelenik meg a hasznos tartalom; és milyen gyorsan reagál a felület a beavatkozásra. A jó mérés megnevezi, melyik kérdésre válaszol.
flowchart LR
B[Böngésző] --> H[Hálózat]
H --> S[Szerver válasza]
S --> L[Erőforrások letöltése]
L --> R[Renderelés és interakció]
Válaszidő és hálózati késleltetés
A válaszidő az az idő, amely egy kérés indításától a válasz megérkezéséig eltelik. Több szakaszból áll (4.6): a kérésnek el kell jutnia a szerverig, a szervernek fel kell dolgoznia, a válasznak vissza kell érkeznie. A hálózati késleltetés részben fizikai adottság (távolság, mobilkapcsolat, zsúfolt hálózat), a szerveroldali feldolgozás pedig függhet adatbázis-lekérdezéstől, más szolgáltatás válaszától vagy a számítás bonyolultságától.
Ha egy API a szerver nézőpontjából 80 ezredmásodperc alatt elkészíti a választ, a felhasználó mégis tapasztalhat fél másodpercet, mire a kérés oda-vissza megteszi útját és a kliens feldolgozza az eredményt. Emiatt a „nálam gyors” nem elég: ugyanaz az oldal más hálózatról, eszközről és földrajzi helyről másként viselkedik.
Backend-mérés és felhasználói mérés
A szerver oldaláról sokszor egy kérés feldolgozási ideje látható. Ez értékes, de a történetnek csak az egyik fele: nem tartalmazza a névfeloldást, a kapcsolat létrejöttét, a mobilhálózat ingadozását, az erőforrások utólagos letöltését, vagy azt, hogy a felhasználó telefonja mennyit küzd a megjelenítéssel. A felhasználói mérés azt nézi, amit a böngészőben ténylegesen megélnek (Core Web Vitals, 9.4). A két nézőpont nem versenytárs: ha a szerveroldali idő jó, de a felhasználói rossz, a vizsgálat a kliens, a hálózat és az erőforrások felé fordul; ha mindkettő romlik, valószínűleg közös ok van.
Terhelés, kapacitás, szűk keresztmetszet
A terhelés (load) jelenthet beérkező kérésszámot, aktív felhasználókat, feldolgozandó üzeneteket, adatbázis-műveleteket vagy hálózati forgalmat. A kapacitás az a mennyiség, amelyet a rendszer az elvárt minőség mellett kezelni tud. A szűk keresztmetszet az a komponens, amelyik először telítődik (egy processzor, egy adatbázis-kapcsolatkészlet, egy külső szolgáltatás), és ezzel az egész rendszer teljesítményét meghatározza.
A kapacitás közelében a válaszidő nem lineárisan, hanem „térdszerűen” romlik: a kérések sorban állnak egymásra várva, és minden további kérés még tovább vár.
Kipróbálva: a térd
Egy kis kipróbáló szervert írtunk, amely egy szálon dolgozik, és minden kérésre 10 ezredmásodperc processzoridőt használ, vagyis a kapacitása elvileg kb. 100 kérés/másodperc. Egy kliens különböző ütemben (kérés/másodperc) küldött kéréseket, 8 másodpercen át mindegyik ütemben, és mértük a válaszidőt (Node.js 24, egy gépen, helyi hálózaton):
Beérkező kérés/s
Átlag (ms)
p50 (ms)
p95 (ms)
p99 (ms)
20
12
12
15
28
50
10
10
10
11
80
11
10
10
20
90
10
10
11
11
95
12
10
20
54
105
229
217
463
1265
Mit látunk?
A kapacitás alatt (20–90 kérés/s) a válaszidő lényegében állandó, kb. 10 ms, vagyis a kérés saját feldolgozási ideje.
95 kérés/s-nál az átlag még jó, de a p95 és a p99 már emelkedik (20 és 54 ms): a gyenge jel a lassú kivételekben jelenik meg előbb, mint az átlagban.
A kapacitás fölött (105 kérés/s) a sor nő: a p99 több mint egy másodperc, az átlag a tízszeresére ugrott, pedig a terhelés csak 5–10%-kal nőtt. Mivel az érkezés gyorsabb, mint a kiszolgálás, a várakozási sor a mérés végéig tovább hosszabbodik.
(Az első sor átlagát kissé torzítja, hogy a JavaScript-futtató az első kérések alatt „bemelegszik”. A kiszolgáló valós kapacitása a környezettől függ; a lényeg a jelenség alakja, nem a konkrét számok.)
Ez a kapcsolat lehetővé teszi, hogy egy kis többlet is látványos összeomlást váltson ki: ezért kell a kapacitás tartalékkal működni, és ezért nem szabad a rendszert mindig a határán futtatni. A következő leckék (10.4, 10.5) azt mutatják meg, mit lehet tenni, ha a terhelés mégis átlépi a határt.
Betöltési idő: nem egyetlen pillanat
A betöltési időt gyakran egyetlen számmal jellemzik, pedig a látogató fokozatosan alkot véleményt. Az első pillanatokban azt érzékeli, hogy történt-e bármi; később azt, hogy látható-e a fő tartalom; végül azt, hogy működnek-e a vezérlők. Egy hírportálnál a cím és a cikk eleje legyen hamar látható; egy vásárlási oldalon az ár, az elérhetőség és a kosárgomb; egy adminisztrációs felületen a táblázat első hasznos része. A gyorsaság tehát nem csupán bájtszám, hanem prioritás kérdése (3.4, 9.4).
Erőforrásigény: mit kérünk a látogatótól?
Minden letöltött kép, betűtípus, szkript és mérőkód adatforgalmat, memóriát, processzoridőt és néha akkumulátort igényel. Egy korszerű asztali gépen egy nagy alkalmazás csupán lassabbnak tűnhet, régebbi telefonon vagy lassú hálózaton ugyanaz használhatatlan lehet. A teljesítmény ezért méltányossági kérdés is (9.3). A JavaScript különösen drága, mert nem csak letöltődik: fel is kell dolgozni és futtatni kell. A cél az arányosság: a letöltött és futtatott tartalom szolgálja-e a felhasználó feladatát?
Átlagok helyett eloszlások
A percentilis azt az értéket adja meg, amely alatt a mérések adott százaléka van: a p50 a medián (a tipikus eset), a p95 és p99 a „lassú farok”. A Google SRE-könyve szerint a magas percentilis a hihető legrosszabb esetet mutatja, és a késleltetések eloszlása gyakran ferde, ezért az átlag és a medián nem azonos. A felhasználók közül sokan találkoznak a lassú farokkal: ha egy oldal betöltéséhez több tucat kérés kell, mindegyiknek van esélye lassúnak lenni, és a felhasználó a leglassabbat érzi.
Az időbeli mintázat is számít. A rendszer lehet gyors hétköznap délelőtt, és lassú akkor, amikor mindenki jegyet vesz. A teljesítmény értelmezése mindig kapcsolódjon terheléshez, eszközhöz, hálózathoz és felhasználói feladathoz.
Végigvezetett példa: a gyors API és a lassú jelentkezési oldal
A Kurzuspont fejlesztői azt látják, hogy a kurzuslista API-ja átlagosan 120 ms alatt válaszol. Ebből arra következtetnek, hogy a jelentkezési oldal gyors. A hallgatók mégis panaszkodnak: mobilon sok másodpercig tart, mire kiválaszthatják a kurzust.
Vizsgálatkor kiderül: a kurzusfotók túl nagyok (3.4, 9.4), több külső mérőkód lassítja a betöltést, és a szűrő működéséhez nagy mennyiségű kliensoldali kódot kell feldolgozni. Az API-mérés nem volt hamis, csak nem az egész felhasználói folyamatot mérte. A másik oldalon a nyitás pillanatában a kiszolgáló a térd közelébe kerül: az átlag marad elfogadható, de a p99 elszáll. A megoldás nem egyetlen „gyorsítási trükk”: annak eldöntése, melyik tartalom elsődleges (9.4), mi halasztható, és hogyan készítjük fel a rendszert a csúcsra (10.4, 10.5).
Gyakori tévhitek
Állítás
Pontosítás
„A betöltési idő ugyanaz, mint a szerver válaszideje.”
A szerver válaszideje csak egy komponens.
„A fejlesztő gyors gépén végzett próba elég.”
A felhasználók eszközei és kapcsolatai változatosak.
„A válaszidő a terheléssel arányosan nő.”
A kapacitás közelében nemlineárisan, térdszerűen romlik.
„Az átlag válaszidő jól leírja a minőséget.”
Az átlag elrejti a lassú, de valós eseteket; a p95/p99 mutatja meg.
„Minél több tartalom van az oldalon, annál jobb.”
A korai hasznosságot és a reakciót a felesleges kezdeti terhelés rontja.
Röviden
A szerveroldali válaszidő csak az élmény egyik összetevője; a felhasználói mérés a teljes láncot nézi.
A kapacitás közelében a válaszidő térdszerűen romlik; a gyenge jel a p95/p99-ben jelenik meg előbb.
Válaszidő, terhelés és kapacitás
Célok
A lecke végére meg tudod különböztetni a szerveroldali és a felhasználói oldalon mért időt, el tudod magyarázni, miért romlik a válaszidő nemlineárisan a kapacitás közelében, és tudod, miért percentilisekben gondolkodunk átlag helyett.
Miért nem elég egyetlen szerveroldali idő?
A rendszer teljesítményét nem lehet egyetlen szerveroldali idővel leírni. A hálózat, a szerver, a letöltött erőforrások és a böngésző munkája együtt határozza meg, mikor tud a felhasználó értelmesen cselekedni (9.4). A lecke a szerveroldali kérdést mélyíti el: mi történik a válaszidővel, amikor több felhasználó érkezik egyszerre?
Három külön kérdésre érdemes gondolni: milyen gyorsan válaszol a szerver; milyen gyorsan jelenik meg a hasznos tartalom; és milyen gyorsan reagál a felület a beavatkozásra. A jó mérés megnevezi, melyik kérdésre válaszol.
flowchart LR B[Böngésző] --> H[Hálózat] H --> S[Szerver válasza] S --> L[Erőforrások letöltése] L --> R[Renderelés és interakció]Válaszidő és hálózati késleltetés
A válaszidő az az idő, amely egy kérés indításától a válasz megérkezéséig eltelik. Több szakaszból áll (4.6): a kérésnek el kell jutnia a szerverig, a szervernek fel kell dolgoznia, a válasznak vissza kell érkeznie. A hálózati késleltetés részben fizikai adottság (távolság, mobilkapcsolat, zsúfolt hálózat), a szerveroldali feldolgozás pedig függhet adatbázis-lekérdezéstől, más szolgáltatás válaszától vagy a számítás bonyolultságától.
Ha egy API a szerver nézőpontjából 80 ezredmásodperc alatt elkészíti a választ, a felhasználó mégis tapasztalhat fél másodpercet, mire a kérés oda-vissza megteszi útját és a kliens feldolgozza az eredményt. Emiatt a „nálam gyors” nem elég: ugyanaz az oldal más hálózatról, eszközről és földrajzi helyről másként viselkedik.
Backend-mérés és felhasználói mérés
A szerver oldaláról sokszor egy kérés feldolgozási ideje látható. Ez értékes, de a történetnek csak az egyik fele: nem tartalmazza a névfeloldást, a kapcsolat létrejöttét, a mobilhálózat ingadozását, az erőforrások utólagos letöltését, vagy azt, hogy a felhasználó telefonja mennyit küzd a megjelenítéssel. A felhasználói mérés azt nézi, amit a böngészőben ténylegesen megélnek (Core Web Vitals, 9.4). A két nézőpont nem versenytárs: ha a szerveroldali idő jó, de a felhasználói rossz, a vizsgálat a kliens, a hálózat és az erőforrások felé fordul; ha mindkettő romlik, valószínűleg közös ok van.
Terhelés, kapacitás, szűk keresztmetszet
A terhelés (load) jelenthet beérkező kérésszámot, aktív felhasználókat, feldolgozandó üzeneteket, adatbázis-műveleteket vagy hálózati forgalmat. A kapacitás az a mennyiség, amelyet a rendszer az elvárt minőség mellett kezelni tud. A szűk keresztmetszet az a komponens, amelyik először telítődik (egy processzor, egy adatbázis-kapcsolatkészlet, egy külső szolgáltatás), és ezzel az egész rendszer teljesítményét meghatározza.
A kapacitás közelében a válaszidő nem lineárisan, hanem „térdszerűen” romlik: a kérések sorban állnak egymásra várva, és minden további kérés még tovább vár.
Kipróbálva: a térd
Egy kis kipróbáló szervert írtunk, amely egy szálon dolgozik, és minden kérésre 10 ezredmásodperc processzoridőt használ, vagyis a kapacitása elvileg kb. 100 kérés/másodperc. Egy kliens különböző ütemben (kérés/másodperc) küldött kéréseket, 8 másodpercen át mindegyik ütemben, és mértük a válaszidőt (Node.js 24, egy gépen, helyi hálózaton):
Mit látunk?
(Az első sor átlagát kissé torzítja, hogy a JavaScript-futtató az első kérések alatt „bemelegszik”. A kiszolgáló valós kapacitása a környezettől függ; a lényeg a jelenség alakja, nem a konkrét számok.)
Ez a kapcsolat lehetővé teszi, hogy egy kis többlet is látványos összeomlást váltson ki: ezért kell a kapacitás tartalékkal működni, és ezért nem szabad a rendszert mindig a határán futtatni. A következő leckék (10.4, 10.5) azt mutatják meg, mit lehet tenni, ha a terhelés mégis átlépi a határt.
Betöltési idő: nem egyetlen pillanat
A betöltési időt gyakran egyetlen számmal jellemzik, pedig a látogató fokozatosan alkot véleményt. Az első pillanatokban azt érzékeli, hogy történt-e bármi; később azt, hogy látható-e a fő tartalom; végül azt, hogy működnek-e a vezérlők. Egy hírportálnál a cím és a cikk eleje legyen hamar látható; egy vásárlási oldalon az ár, az elérhetőség és a kosárgomb; egy adminisztrációs felületen a táblázat első hasznos része. A gyorsaság tehát nem csupán bájtszám, hanem prioritás kérdése (3.4, 9.4).
Erőforrásigény: mit kérünk a látogatótól?
Minden letöltött kép, betűtípus, szkript és mérőkód adatforgalmat, memóriát, processzoridőt és néha akkumulátort igényel. Egy korszerű asztali gépen egy nagy alkalmazás csupán lassabbnak tűnhet, régebbi telefonon vagy lassú hálózaton ugyanaz használhatatlan lehet. A teljesítmény ezért méltányossági kérdés is (9.3). A JavaScript különösen drága, mert nem csak letöltődik: fel is kell dolgozni és futtatni kell. A cél az arányosság: a letöltött és futtatott tartalom szolgálja-e a felhasználó feladatát?
Átlagok helyett eloszlások
A percentilis azt az értéket adja meg, amely alatt a mérések adott százaléka van: a p50 a medián (a tipikus eset), a p95 és p99 a „lassú farok”. A Google SRE-könyve szerint a magas percentilis a hihető legrosszabb esetet mutatja, és a késleltetések eloszlása gyakran ferde, ezért az átlag és a medián nem azonos. A felhasználók közül sokan találkoznak a lassú farokkal: ha egy oldal betöltéséhez több tucat kérés kell, mindegyiknek van esélye lassúnak lenni, és a felhasználó a leglassabbat érzi.
Az időbeli mintázat is számít. A rendszer lehet gyors hétköznap délelőtt, és lassú akkor, amikor mindenki jegyet vesz. A teljesítmény értelmezése mindig kapcsolódjon terheléshez, eszközhöz, hálózathoz és felhasználói feladathoz.
Végigvezetett példa: a gyors API és a lassú jelentkezési oldal
A Kurzuspont fejlesztői azt látják, hogy a kurzuslista API-ja átlagosan 120 ms alatt válaszol. Ebből arra következtetnek, hogy a jelentkezési oldal gyors. A hallgatók mégis panaszkodnak: mobilon sok másodpercig tart, mire kiválaszthatják a kurzust.
Vizsgálatkor kiderül: a kurzusfotók túl nagyok (3.4, 9.4), több külső mérőkód lassítja a betöltést, és a szűrő működéséhez nagy mennyiségű kliensoldali kódot kell feldolgozni. Az API-mérés nem volt hamis, csak nem az egész felhasználói folyamatot mérte. A másik oldalon a nyitás pillanatában a kiszolgáló a térd közelébe kerül: az átlag marad elfogadható, de a p99 elszáll. A megoldás nem egyetlen „gyorsítási trükk”: annak eldöntése, melyik tartalom elsődleges (9.4), mi halasztható, és hogyan készítjük fel a rendszert a csúcsra (10.4, 10.5).
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Tanulási források