Ein Cold Start ist die zusätzliche Latenz, wenn eine Serverless-Plattform vor der Ausführung Ihres Codes eine neue Umgebung erstellen und initialisieren muss. Das ist kein Bug, sondern eine Rechnung: Scale-to-Zero bedeutet, dass inaktive Umgebungen abgebaut werden, damit Leerlauf nichts kostet – und die erste Anfrage nach dem Abbau bezahlt den Aufbau. Wer die Phasen, die realen Zahlen und die Stufenleiter der Gegenmaßnahmen kennt, macht aus Cold Starts statt einer diffusen Angst eine Engineering-Entscheidung mit Preisschild.
Das Wichtigste in Kürze
| Frage | Antwort |
|---|---|
| Die Ursache | Scale-to-Zero: keine Leerlaufkosten ⇒ irgendjemand initialisiert bei Bedarf |
| Die Phasen | Zuweisen → Code herunterladen → Runtime starten → Init-Code ausführen → bearbeiten |
| Die Zahlen | Typisch ~100 ms–1 s+; unter 1 % bei gleichmäßigem Traffic, der Großteil bei spärlichem |
| Der vergessene Auslöser | Scale-out bei Parallelität – Warmer können ihn nicht beheben |
| Die Stufenleiter | Zuerst kostenlose Code-Fixes, zuletzt bezahlte, ständig warme Kapazität |
Die fünf Phasen, mit laufender Uhr
COLD START typische Kosten
1 Sandbox zuweisen (Micro-VM / Container) ~50–100 ms
2 Ihr Deployment-Paket herunterladen 50–500 ms ← wächst mit der Bundle-Größe
3 Runtime der Sprache starten 50–1.000 ms ← Interpreter schnell, VM langsam
4 IHREN Init-Code ausführen (Imports, SDK, DB-Verb.) 0 ms–Sekunden ← Ihr größter eigener Hebel
5 Handler aufrufen die eigentliche Arbeit
WARM START = nur Schritt 5 (+ ~1–10 ms Auftauen). Die Umgebung wurde
eingefroren, nicht zerstört – Verbindungen und Caches außerhalb des Handlers
bleiben erhalten; deshalb zahlt sich Init-Disziplin bei jeder späteren Anfrage aus.Der Vergleich, den Sie selbst messen sollten – eine Funktion auf einem ständig laufenden Backend, bei dem das Rennen gar nicht erst beginnt:
// JavaScript / Node.js — Back4app JS SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
const t0 = Date.now();
const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' });
console.log(`Round trip: ${Date.now() - t0} ms`); // consistent p50 ≈ p99
// The FaaS mitigations (warmers, provisioned capacity, bundle diets)
// don't apply here: the process serving this call was already running.// Flutter / Dart — Back4app Flutter SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
final t0 = DateTime.now();
final response = await ParseCloudFunction('averageStars')
.execute(parameters: {'movie': 'Arrival'});
print('Round trip: ${DateTime.now().difference(t0).inMilliseconds} ms');
// Consistent p50 ≈ p99: the process serving this call was already running.// iOS / Swift — Back4app Swift SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
let t0 = Date()
let avg: Double = try await Cloud.run(name: "averageStars",
parameters: ["movie": "Arrival"])
print("Round trip: \(Int(Date().timeIntervalSince(t0) * 1000)) ms")
// Consistent p50 ≈ p99: the process serving this call was already running.// Android / Kotlin — Back4app Android SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
val t0 = System.currentTimeMillis()
val avg = ParseCloud.callFunction<Double>(
"averageStars", mapOf("movie" to "Arrival"))
println("Round trip: ${System.currentTimeMillis() - t0} ms")
// Consistent p50 ≈ p99: the process serving this call was already running.Cold Starts vs. Warm Starts
| Cold Start | Warm Start | |
|---|---|---|
| Umgebung | Jetzt erstellt und initialisiert | Wiederverwendet, aufgetaut |
| Zusätzliche Latenz | ~100 ms bis Sekunden | Einstellige Millisekunden |
| Wann | Erster Aufruf, nach Deployment, nach Leerlauf, beim Scale-out | Gleichmäßiger Traffic innerhalb des warmen Pools |
| Init-Code | Läuft | Übersprungen – seine Ergebnisse bleiben erhalten |
| Hinweis zur Abrechnung | Bei großen Plattformen wird die Init-Phase inzwischen wie Ausführungszeit berechnet | Nur die Handler-Zeit |
Wie lange und wie oft – ehrlich betrachtet
Die Dauer hängt vor allem von Runtime und Bundle ab: interpretierte Runtimes (JavaScript, Python) typischerweise 200–400 ms, kompilierte (Go, Rust) unter ~100–300 ms, VM-basierte (JVM, .NET) 500 ms bis mehrere Sekunden, wobei Snapshot-Restore den JVM-Wert drastisch senkt. Die p99-Werte liegen beim 2- bis 3-Fachen des Medians, und aufgeblähte Abhängigkeitsbäume vervielfachen die Startzeit unabhängig von der Sprache, während Hello-World-Benchmarks die Basislinie jeder Runtime zeigen. Bei der Häufigkeit erzählen die meisten Erklärungen nur die halbe Geschichte. Gleichmäßiger Produktions-Traffic sieht Cold Starts bei unter einem Prozent der Aufrufe – beruhigend und zutreffend. Bei spärlichem Traffic kehrt sich die Rechnung jedoch um, wie Mike Roberts vorrechnet: Eine Funktion, die einmal pro Stunde aufgerufen wird, startet praktisch jedes Mal kalt, und Entwicklungsumgebungen sehen Cold-Start-Raten von 30–90 %. Dazu kommt der Auslöser, den alle vergessen: Scale-out bei Parallelität. Treffen zehn Anfragen ein und sind drei Umgebungen warm, starten sieben gleichzeitig kalt – mitten in Ihrer Lastspitze, also genau dann, wenn es wehtut.
Die Stufenleiter der Gegenmaßnahmen, mit Preisen
Nach Kosten geordnet, die günstigste zuerst. Kostenlos, im Code: Verkleinern Sie das Deployment-Bundle und dünnen Sie die Abhängigkeiten aus – der größte Hebel, den die meisten Teams noch nicht gezogen haben; importieren Sie nur die SDK-Submodule, die Sie tatsächlich nutzen; laden Sie schwere Module für seltene Codepfade verzögert; öffnen Sie Datenbankverbindungen im Init-Scope, damit Warm Starts sie wiederverwenden. Günstig, per Konfiguration: Weisen Sie mehr Arbeitsspeicher zu (die CPU skaliert mit, bei VM-Runtimes spürbar); aktivieren Sie Snapshot-Restore, wo die Plattform es anbietet. Fragil, ein Hausmittel: Keep-warm-Pings – eine geplante Anfrage alle paar Minuten hält eine Umgebung warm und hilft beim Scale-out überhaupt nicht; ehrlich eingeordnet: ein Relikt. Kostenpflichtig, endgültig: vorab bereitgestellte Kapazität (“Provisioned Concurrency”, “Mindestinstanzen”) – N Umgebungen sind immer initialisiert, Cold Starts bis N entfallen, zu einem Dauerpreis, der die nutzungsbasierte Abrechnung teilweise aufhebt. Die Ironie verdient einen eigenen Satz: Die Lösung für das Kernproblem von Serverless besteht darin, den Server zurückzukaufen, den Sie angeblich nicht mehr haben sollten.
Isolates: wie Edge-Runtimes das Problem umgehen
Edge-Plattformen melden nahezu keine Cold Starts, weil sie die Architektur ändern, statt sie vorzuwärmen: Anstatt pro Tenant einen Container oder eine Micro-VM zu booten, betreiben sie Tausende V8-Isolates – Sandboxes nach dem Vorbild von Browser-Tabs – in einem einzigen, lang laufenden Prozess. Ein Isolate-Kontext kostet wenige Millisekunden und Megabyte, nicht Hunderte Millisekunden und einen Runtime-Start. Der Preis ist die Umgebung: eine Teilmenge der Web-Standard-APIs, enge CPU-Limits, kein Dateisystem – ein anderes Werkzeug, kein kostenloses Upgrade, wie der Edge-Eintrag offen beschreibt.
Typische Anwendungsfälle, in denen Cold Starts zählen
- Interaktive APIs – ein Mensch schaut auf den Spinner; der p99 enthält den kalten Tail.
- Zahlung und Checkout – latenzempfindlich, und jede Verzögerung kostet Conversions.
- Anmeldung und Session-Ausgabe – der Pfad des ersten Eindrucks, oft nach Leerlaufphasen.
- Endpoints mit spärlichem Traffic – Admin-Tools und interne APIs, bei denen fast jeder Aufruf kalt ist.
- Wo sie keine Rolle spielen: Jobs in Queues, Webhooks, geplante Aufgaben – asynchrone Verarbeitung schluckt den Tail unbemerkt.
Sollten Sie Cold Starts optimieren? Eine Entscheidungsmatrix
| Situation | Maßnahme |
|---|---|
| Asynchrone, gequeuete oder geplante Workloads | Nichts – Cold Starts sind hier unsichtbar |
| Gleichmäßig hoher Traffic, interaktiv | Fixes im Code; messen, bevor Sie bezahlen |
| Spärlicher Traffic, nutzernah | Mindestinstanzen auf diesem Pfad – oder ein ständig aktives Backend |
| VM-Runtime (JVM/.NET), latenzempfindlich | Zuerst Snapshot-Restore + Arbeitsspeicher |
| Spitzenlastiger Traffic mit striktem p99 | Bereitgestellte Kapazität, auf die Spitze dimensioniert |
| Gateway-artige Logik, weltweite Nutzer | Isolate-basierte Edge-Runtimes |
| Die meisten App-Backends auf einem BaaS | Bereits gelöst – es gibt kein Scale-from-Zero |
Grenzen und Trade-offs
- Gegenmaßnahmen tauschen Geld gegen Latenz. Vorgewärmte Kapazität ist eine Dauerrechnung; entscheiden Sie pro Endpoint, nicht plattformweit.
- Warmer täuschen Dashboards. Eine gepingte Funktion wirkt gesund, während jede echte Lastspitze beim Scale-out weiterhin kalt startet.
- Sparsamkeit beim Init hat Grenzen. Aggressives Lazy Loading verschiebt die Latenz von Cold Starts auf die Pfade der ersten Nutzung – messen Sie, wohin Sie sie verschoben haben.
- Benchmarks altern schnell. Runtime-Rankings und Plattformzahlen verschieben sich jährlich; veraltete Werte (und längst behobene Netzwerkaufschläge) kursieren weiter – datieren Sie Ihre Daten.
- Entscheidend ist Ihre eigene Metrik. Prozentangaben zu Cold Starts beschreiben den Traffic anderer; nur Ihr p99 unter produktionsnaher Last rechtfertigt Ausgaben.
Cold Starts mit Back4app
Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Beim Thema Cold Starts glänzt sie durch architektonische Abwesenheit: Cloud Code läuft in einem ständig aktiven Backend, also gibt es keinen Scale-from-Zero-Moment – kein Rennen gegen die Init-Phase, keinen warmen Pool zu verwalten, keinen Posten für bereitgestellte Kapazität. Die Messung in den Code-Tabs zeigt, was Ihnen das bringt: p50 und p99 liegen dicht beieinander, bei der ersten Anfrage des Tages ebenso wie bei der millionsten. Der Trade-off ist der in BaaS vs. Serverless beschriebene: Sie verzichten auf die feingranulare Abrechnung pro Aufruf und erhalten dafür konstante Latenz und eine angebundene Datenbank – bei nutzernahen App-Backends meist die Seite des Trade-offs, die Ihre Nutzer tatsächlich spüren.
Häufige Fragen
Was ist ein Cold Start?
Die zusätzliche Latenz, wenn eine Serverless-Plattform eine frische Ausführungsumgebung aufbauen muss, bevor Ihre Funktion läuft: Instanz zuweisen, Code herunterladen, Runtime starten, Initialisierungscode ausführen – und erst dann die Anfrage bearbeiten. Ein Warm Start springt direkt zum letzten Schritt.
Wie lange dauert ein Cold Start?
Typischerweise hundert Millisekunden bis über eine Sekunde. Interpretierte Runtimes (JavaScript, Python) liegen bei etwa 200–400 ms, kompilierte (Go, Rust) können unter 100 ms fallen, VM-basierte Runtimes (JVM, .NET) brauchen 500 ms bis mehrere Sekunden – am schlimmsten sind Setups mit schweren Frameworks. Die Tail-Latenzen liegen beim Zwei- bis Dreifachen des Medians.
Was ist der Unterschied zwischen einem Cold Start und einem Warm Start?
Ein Warm Start verwendet eine eingefrorene, aber bereits initialisierte Umgebung wieder: Die Plattform taut sie auf und ruft Ihren Handler auf, was nur wenige Millisekunden kostet. Alles außerhalb des Handlers – Verbindungen, Caches, geladene Module – bleibt erhalten. Deshalb zahlt sich eine disziplinierte Initialisierung bei jedem folgenden warmen Aufruf aus.
Wie oft treten Cold Starts auf?
Beide Antworten stimmen: bei gleichmäßigem Produktions-Traffic unter etwa einem Prozent der Aufrufe – bei spärlichem Traffic dagegen die überwältigende Mehrheit, denn eine stündlich aufgerufene Funktion startet fast jedes Mal kalt. Lastspitzen kommen hinzu: Jede gleichzeitige Anfrage oberhalb des warmen Pools löst ihren eigenen Cold Start aus.
Wie lassen sich Cold Starts reduzieren?
Arbeiten Sie sich von kostenlos zu kostenpflichtig vor: Deployment-Bundle verkleinern und Abhängigkeiten ausdünnen (der größte kostenlose Gewinn), selten genutzte Imports verzögert laden, eine schnellere Runtime wählen, mehr Arbeitsspeicher zuweisen (die CPU skaliert mit), Snapshot-Restore nutzen, wo verfügbar – und erst dann für vorgewärmte Kapazität bezahlen.
Was ist Provisioned Concurrency?
Die kostenpflichtige Lösung, auch als Mindestinstanzen verkauft: Die Plattform hält N Umgebungen vorab initialisiert und eliminiert so Cold Starts für Traffic bis N. Die Ironie ist eingepreist – Sie holen ständig anfallende Kosten in ein nutzungsbasiertes Modell zurück. Deshalb gehört sie nur auf latenzkritische Pfade.
Funktionieren Keep-warm-Pings?
Teilweise und nur fragil: Ein geplanter Ping hält eine Umgebung warm, hilft aber nicht, wenn die Parallelität hochskaliert – die zehnte gleichzeitige Anfrage startet kalt, egal wie warm die erste Umgebung ist. Warmer sind ein Relikt aus alten Tagen; Mindestinstanzen sind die offiziell unterstützte Antwort.
Spielen Cold Starts für meine App überhaupt eine Rolle?
Nur dort, wo ein Mensch wartet: auf synchronen, nutzernahen Hot Paths wie interaktiven APIs und Zahlungen. Queues, Webhooks, geplante Jobs und andere asynchrone Arbeit schlucken Cold Starts unbemerkt. Messen Sie die Tail-Latenz unter produktionsnahem Traffic, bevor Sie Geld in das Problem stecken.