Röviden: A váratlan latencia forrása gyakran nem a régió távolsága, hanem a DNS, a kapcsolatfelépítés és a cross-AZ forgalom. Hol keresd a rejtett milliszekundumokat?
Van egy visszatérő rejtély a felhős rendszerekben: a szolgáltatás lassabb, mint amire a komponensek alapján számítanál, és senki nem érti, honnan jön a plusz néhány tíz milliszekundum. A reflex az, hogy a régió távolságát vagy a szolgáltatót hibáztatjuk. A valóságban a rejtett latencia forrása szinte mindig közelebb van: a DNS-ben, a kapcsolatfelépítésben és a belső, zónák közötti forgalomban.
A latencia nem egyetlen szám
A hiba az, hogy a hálózati latenciát egyetlen értékként kezeljük. Valójában rétegekből áll össze: névfeloldás, kapcsolatfelépítés, a titkosított csatorna kiépítése, majd a tényleges adatcsere. Minden réteg hozzáad valamennyit, és a „plusz 40 ms” általában több apró tétel összege, nem egyetlen nagy ok.
Gyanús a DNS
A leggyakrabban alábecsült forrás a névfeloldás. Ha egy szolgáltatás minden híváshoz újra feloldja a célt, és a DNS-válasz nincs jól gyorsítótárazva, akkor minden kérés elején ott egy felesleges kör. Ez különösen fájó nagy hívásszámnál, ahol a sok apró DNS-késleltetés összeadódik.
A kapcsolatfelépítés ára
Minden új kapcsolat kiépítése — a hálózati kézfogás és a titkosított csatorna felállítása — időbe telik. Ha a kliensed nem tartja fenn és nem használja újra a kapcsolatokat, akkor ezt az árat minden hívásnál újra megfizeted. A kapcsolatok újrahasználata (pooling) sokszor drámaian csökkenti a mért latenciát anélkül, hogy az alkalmazáslogikához hozzányúlnál.
A cross-AZ forgalom
Egy másik, könnyen elnézett forrás a zónák közötti (cross-AZ) forgalom. A magas rendelkezésre állás kedvéért a komponensek több zónában futnak — ez helyes —, de ha a forgalom feleslegesen ugrál a zónák között, az mind latenciát és költséget ad hozzá. Egy adatbázis, ami egy másik zónában van, mint a hozzá beszélő szolgáltatás, minden lekérdezéshez hozzátesz egy kis kört.
| Latenciaforrás | Tipikus ok | Olcsó javítás |
|---|---|---|
| DNS-feloldás | Nincs cache, minden híváskor újra | Cache, kapcsolat-újrahasználat |
| Kapcsolatfelépítés | Nincs pooling | Keep-alive, connection pool |
| Cross-AZ ugrálás | Rosszul elhelyezett komponensek | Együtt tartani, ami sokat beszél |
| Downstream lassúság | Lassú lekérdezés | Query- és index-optimalizálás |
Mérj a rétegekben
A rejtett latencia megtalálásához bontsd fel a kérés útját. Az elosztott nyomkövetés (tracing) megmutatja, melyik szakasz mennyi időt tölt: mennyi a névfeloldás, mennyi a kapcsolatfelépítés, mennyi a tényleges downstream hívás. E nélkül csak tippelsz. A trace-ben gyakran azonnal látszik, hogy a „plusz 40 ms” valójában több apró, javítható tétel.
A latencia rétegeinek felbontása
A rejtett latencia megtalálásához nem egyetlen számot, hanem rétegeket kell nézni. A kérés útja névfeloldásból, kapcsolatfelépítésből, a titkosított csatorna kiépítéséből és a tényleges adatcseréből áll össze — és a "plusz 40 ms" általában több apró tétel összege, nem egyetlen nagy ok. Az elosztott nyomkövetés (tracing) megmutatja, melyik szakasz mennyi időt tölt, így nem tippelsz, hanem látod.
A leggyakrabban alábecsült forrás a névfeloldás és a kapcsolatfelépítés: ha a kliens minden híváshoz újra felold és új kapcsolatot épít, akkor minden kérés elején ott egy felesleges kör.
A kapcsolatok újrahasználata
A legnagyobb, legolcsóbb latencianyereség gyakran a kapcsolatok és a névfeloldás újrahasználata. Ha a kliensed fenntartja és újrahasználja a kapcsolatokat (connection pooling, keep-alive), akkor megspórolod a drága kapcsolatfelépítést minden hívásnál. Ehhez semmit nem kell átépíteni az alkalmazáslogikában — csak a klienst kell helyesen konfigurálni.
- Ellenőrizd, hogy a kliens újrahasználja-e a kapcsolatokat.
- Kapcsold be a keep-alive-ot és a connection poolingot.
- Gyorsítótárazd a névfeloldást, ahol lehet.
A downstream mint valódi forrás
Gyakran kiderül, hogy a mért lassúság nagyobb részét nem a hálózat, hanem a downstream adja: egy lassú lekérdezés, egy hiányzó index, egy sorosított külső hívás. Ezek melegen is ott vannak, tehát minden kérésnél számítanak. Ezért a kérés útjának felbontása (mennyi a névfeloldás, a kapcsolat, a downstream) fontosabb, mint a régió távolságát hibáztatni. A javításokat oda tedd, ahol a mérés mutatja, ne ahol sejted.
Mit jelent ez neked?
Ha a rendszered lassabb, mint indokolt, ne a régió távolságát hibáztasd először. A rejtett milliszekundumok jellemzően a névfeloldásban, a kapcsolatfelépítésben és a felesleges cross-AZ forgalomban laknak. A legnagyobb, legolcsóbb nyereség sokszor a kapcsolatok újrahasználata — semmit nem kell átépíteni. Bontsd fel a kérés útját tracinggel, hogy lásd, hol vész el az idő, és a javításokat oda tedd, ahol a mérés mutatja, ne ahol sejted.