Kalte Starts sind wichtig, weil sie genau dann bezahlt werden, wenn ein Benutzer erwartet, dass das System sofort reagiert.
Der häufigste Fehler besteht darin, die Latenz beim kalten Start als eine mysteriöse Cloud-Steuer zu betrachten, die man nicht beeinflussen kann. In der Praxis ist der größte Teil, den Sie kontrollieren können, oft der Initialisierungsweg Ihrer eigenen Funktion.
Wo die Zeit Üblicherweise Verloren Geht
Ein kalter Start kann Folgendes umfassen:
- Runtime-Boot
- Laden des Code-Pakets
- Analysieren von Abhängigkeiten
- Globale Initialisierung
- Datenbank- oder SDK-Setup
Das bedeutet, dass große Bündel und eagere Initialisierungen in der Regel die ersten Bereiche sind, die man überprüfen sollte.
Ein Besseres Muster
Halten Sie den globalen Geltungsbereich leicht:
import { S3Client } from "@aws-sdk/client-s3";
const s3 = new S3Client({});
export async function handler(event: unknown) {
return { ok: true };
}
Und verschieben Sie wirklich seltene schwere Arbeiten tiefer in den Ausführungspfad:
export async function handler(event: { mode: string }) {
if (event.mode === "pdf") {
const { renderPdf } = await import("./pdf.js");
return renderPdf(event);
}
return { ok: true };
}
Das macht nicht jede Anfrage schneller. Es macht den häufigen Pfad günstiger zu starten.
Abwägungen
Provisionierte oder vorgeheizte Parallelität kann das Leiden durch kalte Starts verringern, verändert jedoch auch die Kosten. Die richtige Antwort hängt davon ab, ob die Funktion benutzerorientiert ist, der Datenverkehr spitz zuläuft und die Latenz wichtig genug ist, um die Ausgaben zu rechtfertigen.
Weitere Informationen