Röviden: A cold start a legtöbb API-workloadnál marginális; a rossz architektúra sokkal nagyobb latenciaforrás. Szétszedjük a legelterjedtebb hidegindulás-mítoszokat.
A hidegindulás a serverless körül keringő legszívósabb mítosz. Annyiszor elhangzott, hogy „a Lambda lassú a cold start miatt”, hogy sok csapat eleve elveti a serverlesst, vagy fordítva: minden latenciaproblémát a hidegindulásra fog, és rossz helyre teszi az energiát. Ideje szétszedni a leggyakoribb tévhiteket — nem elméleti alapon, hanem a valós működésből kiindulva.
Mítosz 1: „Minden hívás hideg”
A legelterjedtebb tévhit. A valóságban a futtatókörnyezetek újrahasználódnak: egy melegen tartott környezet sok kérést kiszolgál, mielőtt megszűnne. Egyenletesen terhelt rendszernél a hívások túlnyomó többsége meleg, és a hidegindulás csak a forgalom kis töredékét érinti. A „minden hívás hideg” csak nagyon ritka, lökésszerű forgalomnál közelíti a valóságot.
Mítosz 2: „A cold start mindig felhasználói probléma”
Nem minden hívás felhasználó által várt. Egy aszinkron, háttérben futó feldolgozásnál a hidegindulás plusz néhány tíz-száz milliszekundumát senki nem érzi. A cold start csak ott számít, ahol egy ember valós időben várja a választ — és ott is csak akkor, ha a hideg hívások aránya számottevő.
Mítosz 3: „A megoldás mindig a provisioned concurrency”
A provisioned concurrency valós eszköz, de nem az első és nem is mindig a helyes válasz. Sokszor a valódi ok egy felesleges, teljes SDK-import vagy egy nehéz inicializálási szakasz. A kód- és csomagoptimalizálás olcsóbb, és gyakran elég — a provisioned concurrency fizetős készenlét, amit csak indokolt esetben kell bekapcsolni.
Ami tényleg nagyobb: a downstream
A valós számok általában azt mutatják, hogy a serverless rendszerek észlelt lassúságának nagyobb részét nem a hidegindulás adja, hanem az architektúra:
- Sorosított külső hívások, amik egymásra várnak.
- Egy lassú adatbázis-lekérdezés vagy hiányzó index.
- Agresszív, rosszul beállított retry-k.
- VPC-be helyezett függvény rosszul konfigurált hálózattal.
Ezek melegen is ott vannak, tehát minden hívásnál számítanak — szemben a hidegindulással, ami csak néha.
Amikor a cold start mégis valós
Hogy igazságosak legyünk: van, amikor a hidegindulás tényleg probléma. Ritka, lökésszerű, felhasználó által várt hívásoknál, nehéz futtatókörnyezettel a cold start érezhető. Ilyenkor jogos a SnapStart vagy a provisioned concurrency — de csak miután megmérted, hogy tényleg ez a szűk keresztmetszet, nem pedig a downstream.
A mítoszok sorra döntése
A hidegindulás körüli tévhitek konkrétan cáfolhatók. "Minden hívás hideg" — nem, a futtatókörnyezetek újrahasználódnak, egyenletes terhelésnél a hívások többsége meleg. "A cold start mindig felhasználói probléma" — nem, egy aszinkron, háttérben futó feldolgozásnál senki nem érzi. "A megoldás mindig a provisioned concurrency" — nem, gyakran egy felesleges SDK-import vagy nehéz init a valódi ok, amit olcsóbban is orvosolhatsz.
Ezek a tévhitek azért szívósak, mert egyszerűek és jól hangzanak. De a valós mérés rendre megcáfolja őket — és pont ezért kell mérni, mielőtt bármit optimalizálsz.
A mérés a mítoszok ellen
Mielőtt a hidegindulást hibáztatod, gyűjtsd ki, hány hívás volt ténylegesen hideg, és azok mennyivel voltak lassabbak. Gyakran kiderül, hogy a mért lassúságnak alig van köze a cold starthoz — sokkal inkább egy lassú downstream hívásnak, ami melegen is ott van, tehát minden kérésnél számít.
- Mérd a hideg hívások arányát a teljes forgalomból.
- Nézd meg, felhasználó várja-e egyáltalán a választ.
- Bontsd a latenciát init és downstream részekre.
A méréskultúra mint ellenszer
A hidegindulás-mítoszok szívóssága ellen a legjobb védekezés a méréskultúra. Ha a csapat rutinból méri a valós latenciát — a hideg hívások arányát, a p99-et, a downstream idejét —, akkor a mítoszoknak nincs hova beépülniük. A vélemény helyét átveszi az adat. Ez a szemlélet nem csak a hidegindulásnál hasznos: minden teljesítménydöntést jobb mérésre, mint feltételezésre alapozni. A serverless éppen azért kínál gazdag telemetriát, hogy ne kelljen találgatni.
Mit jelent ez neked?
A hidegindulás valós jelenség, de a köré épült mítoszok félrevezetnek: nem minden hívás hideg, nem minden cold start felhasználói probléma, és nem mindig a provisioned concurrency a válasz. Mérd meg a hideg hívások arányát és hatását, mielőtt bármit optimalizálsz — jó eséllyel kiderül, hogy a downstream latencia a valódi bűnös. A hidegindulást csak akkor kezeld célzottan, ha a mérés tényleg őt mutatja, nem a reflex.