Mój poprzedni artykuł Co to jest cold start Lambdy? Wyjaśnię Ci go w 4 minuty spotkał się z dużą popularnością, więc postanowiłem pociągnąć temat dalej. Dziś wyjaśnię Ci za co płacisz, a za co nie, przy cold starcie funkcji Lambda.
⚡ Zacznijmy od początku: Co wpływa na cold start?
Wyróżniamy 4 elementy:
- Przygotowanie kodu funkcji
- Przygotowanie kontenera
- Przygotowanie runtime’u
- Uruchomienie kodu funkcji
Spójrz na poniższy diagram:
(Uwaga, inaczej to trochę wygląd przy Provisioned Concurrency - tutaj pomijam tę funkcjonalność)
⚡ Nad czym mamy kontrolę?
Bezpośrednio mamy kontrolę nad wyborem runtime’u (punkt 3). JavaScript, Java, Pythone, .NET charakteryzują się różnymi czasami ładowania.
Pośrednio mamy też wpływ na to jak długo będzie się pobierał kod naszej funkcji do kontenera. Ogólnie, im będzie mniejszy tym szybciej.
⚡ Jak to wygląda konkretnie?
W AWS mamy do dyspozycji usługę X-Ray, które jest w stanie pokazać nam bardzo dokładne metryki na temat działania każdej funkcji lambda. Poniżej widzisz metryki wywołania konkretnej funkcji gdzie miał miejsce cold start.
Na czerwono (zielony w dark mode) został zaznaczony cold start za który nie płacimy!
Część zaznaczona na zielono (różowy w dark mode) to czas wykonywania naszej funkcji (dokładniej kodu handler’a).
Pokrywa się to z informacji, które można znaleźć w CloudWatch Logs przy tym konkretnym wywołaniu funkcji.
Duration: 163.67 ms Billed Duration: 200 ms Init Duration: 603.71 ms
Warto tutaj przypomnieć: czas za który płacimy jest zawyżany w górę do pełnych setek milisekund.
Na żółto zaznaczyłem czas potrzeby na przydzielenie kontenera wraz z runtime’em oraz skopiowanie kodu wraz z ustawieniami.
⚡ Za co płacimy?
Podsumowując, płacimy, za czas wykonywania naszego kodu (zaokrąglony w górę), a cold start jest gratis od AWS 😜
