Wat is een koude start?

In serverless computing is een "cold start" de tijd die een functie nodig heeft om te beginnen met verwerken nadat deze lange tijd niet is aangeroepen. Bij AI-inference kan het laden van een model minuten of veel langer duren — zoals bij die ene NetEase Games-workload waarbij het maar liefst 42 minuten duurde. Wanneer een computer wordt ingeschakeld nadat deze is uitgeschakeld, kan het even duren voordat deze zijn volledige prestaties levert.

Cold starts zijn bekend bij iedereen die begint met serverless architecturen. Ze beïnvloeden de prestaties en bruikbaarheid van uw applicatie, vooral bij interacties waarbij time-outs zo kort mogelijk moeten zijn.

Koude starts vinden plaats onder de volgende omstandigheden.

• Eerste aanroep: Dit gebeurt wanneer een functie voor de eerste keer wordt aangeroepen na de implementatie van de applicaties of na een code-update.
• schalen vanaf nul: Wanneer een functie uitbreidt van geen exemplaren te hebben en oproepen ontvangt na een tijdje niet te hebben gewerkt.
• Herverdeling van resources: Wanneer de cloudprovider resources opnieuw toewijst of de basis van de functie naar andere hosts verhuist, kan dit leiden tot koude functie-instanties.
• Time-out of vervaldatum: Als een functie-instantie de maximale uitvoeringstijd heeft bereikt of de inactiviteitstijd heeft overschreden, kan deze worden beëindigd, wat betekent dat als deze opnieuw wordt aangeroepen, deze opnieuw zal starten.

Een warm start heeft het tegenovergestelde effect: het verzoek bereikt een instantie die nog actief is, waardoor de installatie wordt overgeslagen.

Een belangrijke uitdaging die gepaard gaat met koude starts is de extra latentie. Deze latentie kan worden waargenomen in de vorm van:

• Vertraagde reacties: Hoewel uw app over het algemeen snelle antwoorden geeft, kunnen gebruikers af en toe vertragingen ondervinden die hun ervaring kunnen beïnvloeden.
• Gereduceerde doorvoer: Cold starts kunnen een geleidelijke toename vereisen van het vermogen van uw applicatie om gelijktijdige verzoeken te verwerken, vooral tijdens periodes van intensief gebruik.
• Prestatievariaties: Cold start-cijfers variëren per aanroep, dus serverless responstijden kunnen niet worden voorspeld zonder serverless monitoring.

De duur van een Lambda-koude start kan variëren afhankelijk van verschillende factoren, zoals:

• Functieomvang en afhankelijkheden: Hoe groter de functie, hoe meer afhankelijkheden erbij betrokken zijn en hoe langer de typische koude start duurt.
• Runtime-omgeving: De initiële runtime-omgeving die is geselecteerd (bijvoorbeeld Node.js, Python, Java, enz.) bepaalt noodzakelijkerwijs een factor zoals de cold start-tijd vanwege de verschillen in de initialisatie- en laadprocessen.
• Optimalisaties van cloudproviders: In de loop van de tijd bieden cloudproviders consequent optimalisaties om de koude starttijd zoveel mogelijk te verkorten; het is echter niet vast of voorspelbaar.

Over het algemeen kunnen de cold starts van Lambda variëren tussen minder dan 100 ms en meer dan 1 seconde. Controleer uw eigen functies om te zien hoe de duur van de cold start de behoeften van uw functies en omgeving weerspiegelt, om zo nauwkeurige inzichten te verkrijgen.

Minimaliseer de cold start-tijd van Lambda door:

• Functieoptimalisatie:
• Verwijder ongebruikte code en afhankelijkheden om de functiegrootte te verkleinen.
• Tree-shaking- of codesplittingsmethoden moeten worden gebruikt om de hoeveelheid geladen code tijdens initialisatie te verminderen.
• Verbeter de pakketdistributie en de workflows voor het oplossen van pakket afhankelijkheden.
• Snapshot Restore: Lambda SnapStart, voor runtimes zoals Java, biedt een opgeslagen snapshot van een geïnitialiseerde functie in plaats van deze opnieuw op te starten om latentie te verminderen.
• Voorziene gelijktijdigheid:

Configureer ingeroosterde gelijktijdigheid om het specifieke aantal actieve functie-instanties te behouden, zodat de inkomende verzoeken geen cold start veroorzaken voor die instanties.

• Opwarmverzoeken:

Soms moet je enkele dummy-verzoeken naar je functies sturen, zodat ze zijn opgewarmd wanneer de echte gebruikersverzoeken binnenkomen.

• Asynchrone verwerking:

Voor niet-kritieke bewerkingen kan het beter zijn om gebruikersverzoeken van functies te refactoren door andere asynchrone patronen in te voeren, zodat koude starts een minimaal effect hebben.

• Caching:

Voer geschikte caching-mechanismen in die vaak opgevraagde gegevens of vooraf berekende resultaten opslaan om het aantal functieaanroepen te verminderen en zo het aantal cold starts te verlagen. Het vooraf laden van de functie bij het opstarten werkt op dezelfde manier: NetEase Games verkortte de laadtijd van een AI-model van 42 naar 14 minuten met een cache, en vervolgens naar 3 met prefetching (CNCF, 2026).