Wat is een koude start?

In de context van serverloos computing verwijst een “koude start” naar de eerste latentie of de tijd die een functie nodig heeft om te beginnen met verwerken nadat deze lange tijd niet is aangeroepen.  Ter illustratie: wanneer een computer wordt ingeschakeld nadat deze is uitgeschakeld, kan het enige tijd duren voordat deze zijn volledige prestaties bereikt.

Koude starts zijn fundamenteel voor iedereen die begint met serverloze architecturen. Het beïnvloedt de prestaties en bruikbaarheid van uw applicatie, vooral met betrekking tot interacties waarbij time-outduren zo kort mogelijk moeten zijn.

Koude starts vinden plaats onder de volgende omstandigheden.

• Eerste aanroep: Er zijn twee gevallen; de eerste is wanneer een functie voor de eerste keer wordt aangeroepen na de implementatie van de applicaties of na de update van de code.
• 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 verandert naar andere hosts, 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 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: Koude starts kunnen een geleidelijke toename van het vermogen van uw applicatie om gelijktijdige verzoeken af te handelen noodzakelijk maken, vooral tijdens periodes van intensief gebruik.
• Prestatievariaties: De mate waarin de duur van koude starts in de loop van de tijd verandert, kan de effectiviteit van de applicatie beïnvloeden, waardoor mogelijkheden ontstaan om zowel de responstijden te stroomlijnen als de bestendigheid te versterken.

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 koude starts van Lambda variëren van een halve seconde tot een paar seconden. Om nauwkeurige gegevens te verkrijgen en te observeren hoe de duur van de koude start aansluit bij de behoeften van uw functies en omgeving, is het dus belangrijk om nauwkeurige inzichten te verkrijgen.

Hier zijn enkele manieren om de koude starts van Lambda te verkorten of er in ieder geval mee om te gaan:

• 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.

• 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.