Stanowość funkcji Lambda

Witam,
chciałbym poruszyć temat stanowości w funkcji Lambda.

Na początek przykład prostego kodu:

'use strict';

let n = 0;
      
exports.handler = (event, context, callback) => {
    
    n+=1;
    const response = {
        statusCode: 200,
        body: n
    };
    callback(null, response);
}

Jako że funkcja Lambda jest kontenerem, który jest używany do powtórnego wykorzystania (podobno do 15 min) to tylko raz w przeciągu tego czasu inicjuję zmienne globalne, a następnie z nich korzysta…

I tak powyższa funkcja będzie zwracała za każdym razem inny wynik (do 15 min - tak mi sie wydaje…). Jednak nie jest to takie oczywiste tesując lambdę lokalnie (lambda-local) albo za pomocą Serverless Framework, bo one za każdym razem inicjują zmienne od nowa…Dopiero testując funkcję manualnie z poziomu konsoli można to zauważyć.

Ma to swoje plusy bo można cachować różne zasoby (np żadania do DynamoDB, tym samym oszczędzając na przeszukiwaniu tabeli…). Jednak, tak jak w powyższym przykładzie widać, niektore zmienne nie powinny być buforowane.

I tutaj moje pytanie, jak najlepiej testować taką funkcję symulując warunki produkcyjne wraz z wieloma współbieżnymi żądaniami…Macie może jakiś prosty przykład zautomatyzowanego wysyłania żądań z wiersza poleceń, tak aby móc je dowolnie mnożyć…?

Jak się domyślam, można to zrobić na dwa sposoby, albo mnożąc żądania z poziomu kodu, czyli wykorzystując np. funckję setInterval, albo za pomocą skryptu bash’owego…Czy praktykuję się takie rzeczy?

Dzięki!

Widzę, że w czasie mojej nieobecności spowodowanej grypą nikt się nie podjął odpowiedzi… :unamused:

Aby być dokładnym to nie jest kontenerem, kod jest wykonywany w kontenerze :slight_smile:

To 15 minut to źle Ci się wydaje. Pisałem o tym dokładniej w moim poradniku 12 rzeczy o serverless, przeczytaj punkt 7.

Tak zgadza się, każdy nowy klient który trafi na rozgrzaną funkcję otrzyma ją wraz z zainicjalizowanymi zmiennymi globalnymi.

Jak Ci zależy na lokalnym testowaniu to możesz przecież zrobić dwa suity testów jednostkowych. Jeden testujący zimną funkcję n=0 i drugi ciepłą np. n=3 lub dowolny inny stan nie-wejściowy.

To nie rób z nich zmiennych globalnych :stuck_out_tongue:

Znów Cie odsyłam do 12 rzeczy o serverless. Na przygotowanie takiego środowiska możesz stracić więcej czasu niż na implementacje. Lepiej stwórz sobie stage dev i testuj w chmurze. To już będą testy integracyjne.

Dzisiaj dopiero podjąłem sie przeczytania wszystkich Twoim punktów poradnika.

Polecam wszystkim tą lekturę, bo ja za piewszym razem zrobilem to po łebkach…

Zależy mi na lokalnym testowaniu bo wszystkie informacje mam jak na dłoni, no i nie muszę przesyłać tego na serwer…

Ok, dzięki Paweł za, jak zwykle wyczerpująca odpowiedz. Pozdrawiam :slight_smile: