Les démarrages à froid blessent le plus lorsque les fonctions font trop avant que le gestionnaire ne s'exécute_

Les démarrages à froid comptent car ils sont ressentis exactement au moment où un utilisateur s'attend à ce que le système soit instantané.

L'erreur commune est de considérer la latence de démarrage à froid comme une taxe mystérieuse du cloud que vous ne pouvez pas influencer. En pratique, la plus grande partie que vous contrôlez est souvent votre propre chemin d'initialisation de fonction.

Où le temps part généralement

Un démarrage à froid peut inclure :

• démarrage d'exécution
• chargement du package de code
• analyse des dépendances
• initialisation globale
• configuration de la base de données ou SDK

Cela signifie que de grands bundles et une initialisation impatiente sont généralement les premiers endroits à examiner.

Un meilleur modèle

Gardez la portée globale légère :

import { S3Client } from "@aws-sdk/client-s3";
 
const s3 = new S3Client({});
 
export async function handler(event: unknown) {
  return { ok: true };
}

Et déplacez le travail lourd vraiment rare plus profondément dans le chemin d'exécution :

export async function handler(event: { mode: string }) {
  if (event.mode === "pdf") {
    const { renderPdf } = await import("./pdf.js");
    return renderPdf(event);
  }
 
  return { ok: true };
}

Cela ne rend pas chaque requête plus rapide. Cela rend le chemin commun moins cher à démarrer.

Compromis

La concurrence provisionnée ou préchauffée peut réduire la douleur des démarrages à froid, mais cela change également le coût. La bonne réponse dépend de savoir si la fonction est orientée utilisateur, si le trafic est paroxystique, et si la latence est suffisamment importante pour justifier la dépense.

Lectures complémentaires

• Environnement d'exécution AWS Lambda
• Optimisation des performances AWS Lambda