AWS / Cloud
Mémoire Lambda : comparer durée et coût selon la charge
Mesurer la durée et les GB·ms sur plusieurs exécutions, comparer leur variabilité et choisir le prochain réglage à tester.
La mémoire allouée peut modifier la durée et le coût de calcul d’une Lambda, selon sa charge. Si vous exploitez une fonction Lambda, comparez les réglages avec la même entrée et une cible de latence définie : cherchez le prochain réglage à tester, pas une taille optimale universelle.
Préparer la comparaison
Fixez l’entrée, la version du code, le runtime, l’architecture, la région et les dépendances sollicitées. Notez la configuration de concurrence et comparez séparément les invocations avec initialisation et celles dont l’environnement est déjà disponible. Définissez la latence acceptable et la marge mémoire recherchée avant de lire les résultats.
Pour chaque invocation, relevez la mémoire configurée, Duration, Billed Duration et Max Memory Used dans les rapports disponibles pour votre runtime; conservez Init Duration lorsqu’il est présent. Une durée du handler mesurée par le programme reste distincte de Duration. Gardez les valeurs individuelles et les erreurs pour examiner la dispersion, puis répétez la charge à chaque taille. Une entrée ou une dépendance différente empêche d’attribuer l’écart à la seule mémoire.
Lire deux campagnes en exemple
Dans la réalisation Lambda du portfolio, le même programme Java 25 renvoie 78 498 à 256, 1 024 et 2 048 MB. Deux campagnes de cinq exécutions par taille donnent ces moyennes. Elles ne permettent pas de reconstituer les valeurs individuelles, la dispersion ou les conditions cold/warm.
| Campagne | Mémoire | Durée du handler moyenne | Durée facturée moyenne | GB·ms |
|---|---|---|---|---|
| Première | 256 MB | 1 008,8 ms | 1 030,2 ms | 257,55 |
| Première | 1 024 MB | 245,2 ms | 248,2 ms | 248,2 |
| Première | 2 048 MB | 123 ms | 126,4 ms | 252,8 |
| Dernière | 256 MB | 969 ms | 986 ms | 246,5 |
| Dernière | 1 024 MB | 139 ms | 141,6 ms | 141,6 |
| Dernière | 2 048 MB | 142,4 ms | 145,2 ms | 290,4 |
La première campagne donne la latence la plus basse à 2 048 MB, avec un coût de calcul comparable en GB·ms. La dernière donne à 1 024 MB à la fois la latence la plus basse et le plus petit indicateur GB·ms. Le classement change d’une campagne à l’autre.
Durée et coût de calcul
Lambda alloue le CPU en proportion de la mémoire configurée. Augmenter la mémoire peut donc accélérer une charge CPU, même si le programme n’approche pas sa limite mémoire. La documentation AWS recommande d’observer les fonctions et de mesurer la durée.
Les GB·ms du tableau sont calculés par (mémoire en MB / 1 024) × durée facturée en ms. Ainsi, 256 MB et 1 030,2 ms donnent 257,55 GB·ms selon cette convention, soit 0,25755 Gio·s en secondes. Cet indicateur de calcul ne couvre pas tous les postes d’une facture. Ils ne représentent pas un montant en dollars; une estimation de facture dépend notamment de la région, de l’architecture et des tarifs applicables.
Choisir quoi retester
| Question | Indice utile | Décision suivante |
|---|---|---|
| La fonction approche-t-elle sa mémoire maximale ? | Max Memory Used dans les rapports d’invocation |
Vérifier la marge et tester une allocation supérieure si nécessaire. |
| Le handler est-il limité par le calcul ? | Durée du handler et comparaison sur une charge répétée | Tester plusieurs tailles mémoire avec le même input et les mêmes conditions. |
| Le classement varie entre campagnes ? | Résultats répétés et dispersion, pas uniquement la moyenne | Augmenter le nombre d’essais et distinguer initialisation, charge et variabilité de l’environnement. |
| Quel réglage garder ? | Latence cible, mémoire maximale, GB·ms et coût de l’environnement visé | Comparer les résultats aux événements, aux dépendances et aux objectifs de latence de la fonction. |
Si les classements divergent, élargissez les répétitions représentatives et examinez les valeurs individuelles avant de retenir un candidat répondant à votre cible de latence et à votre marge mémoire.