Cloudflare Workers Smart Placement: DB-Latenz 80% senken

Das Edge-Computing-Paradoxon: Warum ist meine Serverless-Funktion langsamer?

„Cloudflare Workers werden in über 300 Edge-Rechenzentren weltweit mit einer Latenz von unter 5 ms ausgeführt.“

Hinter diesem perfekt klingenden Werbeslogan verbirgt sich ein hartnäckiges Problem, mit dem viele Entwicklerteams bei der Einführung einer Serverless-Edge-Architektur konfrontiert werden: das „Edge-Paradoxon (Edge Paradox)“.

Nehmen wir an, ein Benutzer in Südkorea verbindet sich mit dem Cloudflare-Edge-Rechenzentrum in Seoul und führt einen Worker aus. Die Ausführung des Codes dauert nur 2 ms. Was passiert jedoch, wenn dieser Worker eine RDS PostgreSQL- oder MongoDB-Datenbank in US-Ost (AWS us-east-1) abfragen muss, um Benutzerprofildaten, Bestellhistorie oder Berechtigungen zu überprüfen?

[Benutzer (Seoul)] --- (2ms) ---> [Cloudflare Seoul Edge (Worker-Ausführung)]
                                     |
                                  (160ms RTT)
                                     v
                           [AWS RDS (us-east-1)]

Die Ausführung des Workers selbst ist zwar nach 2 ms abgeschlossen, jedoch entsteht zwischen dem Edge-Rechenzentrum in Seoul und der Datenbank in US-Ost eine Netzwerk-Paketumlaufzeit (RTT; Round Trip Time) von über 160 ms. Was passiert, wenn innerhalb einer einzelnen Anfrage 3 DB-Abfragen nacheinander ausgeführt werden? Ohne Optimierung erlebt der Benutzer eine Latenz von mehr als 500 ms (0,5 Sekunden). Ironischerweise wird die Edge-Funktion, die ganz in der Nähe des Benutzers ausgeführt wird, dadurch deutlich langsamer als ein zentraler Server.

Um diese Herausforderung zu bewältigen, bietet Cloudflare mit Smart Placement und Smart Tiered Cache (Cloud Region Hints) zwei globale Routing-Optimierungstechnologien der nächsten Generation. In diesem Leitfaden erfahren Sie, wie diese beiden Schlüsseltechnologien funktionieren und wie Sie globale Latenzzeiten durch bloße Konfiguration – ganz ohne eine einzige Zeile Codeänderung – um mehr als 80 % reduzieren.

Funktionsweise von Smart Placement: Eliminierung von Ping-Pong-RTT

Herkömmliches Edge-Routing vs. Smart Placement Routing

Smart Placement ist eine intelligente Orchestrierungs-Engine, die den Ausführungsort von Workers automatisch vom „dem Benutzer am nächsten gelegenen Edge“ zum „der Datenbank / dem Backend-Origin am nächsten gelegenen Edge“ verlagert (Re-Location).

1. Herkömmliches Routing (Default Placement)

• Anfrage von einem Benutzer in Seoul → Worker wird sofort am Edge-Rechenzentrum in Seoul ausgeführt
• Innerhalb des Workers werden 3 Abfragen an die Origin-DB in us-east-1 gesendet
• Gesamtlatenz: 2 ms + (160 ms × 3) = 482 ms

2. Nach Aktivierung von Smart Placement

• Anfrage von einem Benutzer in Seoul → Das Cloudflare-Netzwerk leitet die Anfrage transparent direkt an den Edge neben dem us-east-1-Backend (z. B. Edge-Rechenzentrum Washington D.C.) weiter
• Der Worker wird auf dem Edge-Server direkt neben us-east-1 ausgeführt und verarbeitet alle 3 DB-Abfragen
• Latenz zwischen den DB-Abfragen: unter 1 ms!
• Gesamtlatenz: (Seoul↔us-east-1 RTT über das dedizierte Cloudflare-Backbone 150 ms) + (1 ms × 3) = 153 ms

+-----------------------------------------------------------------------+
| Routing-Ablauf bei aktivierter Smart Placement                        |
+-----------------------------------------------------------------------+

[Benutzer (Seoul)]
      |
 (Nur 1 Hop in Lichtgeschwindigkeit über das globale Cloudflare-Backbone)
      v
[Cloudflare US-East Edge (Worker-Ausführung via Smart Placement verlagert)]
      | (1ms RTT)
      +---> [DB Query 1]
      +---> [DB Query 2]
      +---> [DB Query 3]
      v
[AWS us-east-1 RDS / Aurora Database]

Über das bewährte globale Backbone-Netzwerk von Cloudflare wird nur ein einziger Hop mit Lichtgeschwindigkeit ausgeführt. Die mehrfachen DB-Verbindungs- und Abfrage-Ping-Pongs werden im 1-ms-Routingbereich direkt neben dem Backend verarbeitet, wodurch die Gesamtantwortzeit drastisch um 70 bis 80 % oder mehr gesenkt wird.

Automatischer Analyse-Algorithmus von Smart Placement

Bei Smart Placement müssen Entwickler nicht manuell festlegen, dass eine bestimmte Funktion neben us-east-1 ausgeführt werden soll. Die Machine-Learning-Analyse-Engine im Hintergrund von Cloudflare (integriert in die Pingora-Engine) analysiert die Echtzeit-Telemetriedaten jedes Workers und bestimmt den optimalen Modus automatisch.

1. Anfrage-Profiling: Erkennt ausgehende fetch()-Aufrufe, Hyperdrive-Verbindungen und externe API-Adressen, die vom Worker aufgerufen werden.
2. RTT-Messung: Misst die RTT-Latenz und die Abfragefrequenz bei allen ausgehenden Anfragen im Hintergrund.
3. Platzierungsoptimierung:
   • DB-/Origin-rechenintensive Workers: Smart Placement aktivieren, um den Worker nahe am Origin-Backend auszuführen.
   • Einfaches HTML-Rendering / KV / R2 Edge-only Workers: Default Placement beibehalten, um die Ausführung am benutzernahen Edge (Eyeball Edge) zu belassen.

Schritt 1: Smart Placement in wrangler.jsonc aktivieren

Die Konfiguration ist denkbar einfach. Es reicht aus, das placement-Objekt in der Datei wrangler.jsonc (oder wrangler.toml) hinzuzufügen, um die Funktion sofort zu aktivieren.

// wrangler.jsonc
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-global-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"],

  // Smart Placement-Konfiguration hinzufügen
  "placement": {
    "mode": "smart"
  },

  // Bei Anbindung externer PostgreSQL-Datenbanken erzielt die Kombination mit Hyperdrive maximale Wirkung
  "hyperdrive": [
    {
      "binding": "HYPERDRIVE",
      "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  ]
}

Alternativ in der wrangler.toml-Konfiguration:

# wrangler.toml
name = "my-global-api"
main = "src/index.ts"
compatibility_date = "2026-01-01"

[placement]
mode = "smart"

Nach dem Deployment können Sie im Cloudflare-Dashboard unter Workers & Pages -> [Ihr Worker] -> Settings -> Placement den von Cloudflare ermittelten optimalen Rechenzentrumsstandort sowie Metriken zur Latenzreduzierung in Echtzeit einsehen.

Schritt 2: Smart Tiered Cache & Cloud Region Hints konfigurieren

Während Smart Placement die Compute-Logik (Berechnung) direkt neben den Backend-Origin verlagert, ist Smart Tiered Cache eine Technologie, die beim Caching von Daten (Inhalten) automatisch das dem Origin am nächsten gelegene Upper-Tier-Rechenzentrum (Upper-tier Data Center) zuweist.

Cloud Region Hints (Neue Funktion 2025/2026)

Beim herkömmlichen Tiered Cache kam es aufgrund von Anycast-Routing-Eigenschaften gelegentlich vor, dass bei einem Cache-Miss ein europäisches Upper-Tier-Rechenzentrum angesteuert wurde, obwohl sich der Origin-Server in AWS us-east-1 befand.

Cloudflare hat dieses Problem durch die Einführung des Cloud Region Hints-Flags gelöst. Durch die explizite Angabe der Public-Cloud-Region Ihres Origins können Sie erzwingen, dass bei Cache-Misses alle 300 Edge-Standorte weltweit direkt auf den dedizierten Upper-Tier-Cache-Server zugreifen, der nur 1 ms vom Origin entfernt liegt.

// src/index.ts (Hono.js-basierte Antwort-Cache-Konfiguration)
import { Hono } from "hono";
import { cache } from "hono/cache";

type Env = {
  HYPERDRIVE: Hyperdrive;
};

const app = new Hono<{ Bindings: Env }>();

// 1. Cache-Header mit Cloud Region Hint und Tiered-Cache-Direktiven versehen
app.get("/api/products", async (c) => {
  // Produktliste aus der DB abfragen (Smart Placement verarbeitet dies direkt neben dem Backend)
  const client = new Client(c.env.HYPERDRIVE.connectionString);
  await client.connect();
  const result = await client.query("SELECT * FROM products WHERE is_active = true");
  
  c.header("Cache-Control", "public, max-age=60, s-maxage=3600");
  
  // Cloudflare-spezifische Cache-Tags und Cloud Region Hint Header (AWS us-east-1 Origin angegeben)
  c.header("CF-Cache-Tag", "products-list");
  c.header("CF-Placement-Hint", "aws/us-east-1");

  return c.json(result.rows);
});

export default app;

Schritte im Cloudflare-Dashboard:

1. Navigieren Sie zu Caching -> Tiered Cache
2. Aktivieren Sie die Option Smart Tiered Cache (On)
3. Überprüfen Sie bei Verwendung von AWS, GCP oder Azure, ob die automatische Erkennung der Cloud-Anbieter-Region abgeschlossen ist

Schritt 3: Praxisnahe Architektur-Implementierung (Hono.js + Drizzle ORM + Smart Placement)

Erstellen wir eine optimale Backend-Pipeline für eine Produktionsumgebung, die Hono.js, Drizzle ORM, Hyperdrive und Smart Placement kombiniert.

// src/db/schema.ts
import { pgTable, serial, text, timestamp, doublePrecision } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull().unique(),
  name: text("name").notNull(),
  createdAt: timestamp("created_at").defaultNow().notNull(),
});

export const orders = pgTable("orders", {
  id: serial("id").primaryKey(),
  userId: text("user_id").notNull(),
  amount: doublePrecision("amount").notNull(),
  createdAt: timestamp("created_at").defaultNow().notNull(),
});

// src/index.ts
import { Hono } from "hono";
import { drizzle } from "drizzle-orm/node-postgres";
import Client from "pg";
import { users, orders } from "./db/schema";
import { eq } from "drizzle-orm";

type Env = {
  HYPERDRIVE: Hyperdrive;
};

const app = new Hono<{ Bindings: Env }>();

// Middleware: DB-Connection-Pooling und Latenzmessung
app.use("*", async (c, next) => {
  const start = performance.now();
  await next();
  const duration = performance.now() - start;
  c.header("Server-Timing", `total;dur=${duration.toFixed(2)}`);
});

// Komplexe Geschäftslogik: Benutzerdaten abfragen + Letzte 5 Bestellungen abfragen + Statistiken berechnen (Mehrere DB-Abfragen)
app.get("/api/user-dashboard/:userId", async (c) => {
  const userId = c.req.param("userId");

  // PG-Client über Hyperdrive-Verbindung erstellen (Dank Smart Placement in unmittelbarer Nähe von us-east-1 ausgeführt)
  const client = new Client({ connectionString: c.env.HYPERDRIVE.connectionString });
  await client.connect();
  const db = drizzle(client);

  try {
    // 1. Abfrage: Benutzer überprüfen
    const user = await db.select().from(users).where(eq(users.email, userId)).limit(1);
    if (!user.length) {
      return c.json({ error: "User not found" }, 404);
    }

    // 2. Abfrage: Letzte Bestellungen abfragen
    const userOrders = await db
      .select()
      .from(orders)
      .where(eq(orders.userId, userId))
      .limit(5);

    // 3. Abfrage: Aggregationsberechnung
    const totalSpent = userOrders.reduce((sum, order) => sum + order.amount, 0);

    return c.json({
      user: user[0],
      recentOrders: userOrders,
      summary: {
        totalSpent,
        orderCount: userOrders.length,
      },
    });
  } finally {
    // Benutzerdefinierte Ressourcenfreigabe
    c.executionCtx.waitUntil(client.end());
  }
});

export default app;

Benchmark: Latenz-Vergleichstest (Latency Metrics)

Dies sind die Benchmark-Ergebnisse von 1.000 Testanfragen, die von 5 Hauptstädten weltweit (Seoul, Tokio, London, Frankfurt, Sydney) an eine Workers-API mit einem AWS us-east-1 RDS PostgreSQL-Backend in den USA gesendet wurden.

P95-Latenz bei 3 DB-Abfragen pro Anfrage (ms)

Ergebnisanalyse

• Bei Default Placement wurde der Worker zwar am Edge nahe am Benutzer ausgeführt, wodurch der initiale Verbindungsaufbau schnell war. Allerdings fielen für jede der 3 DB-Abfragen jeweils 160 ms RTT seriell zwischen Seoul und den USA an, was zu einer P95-Latenz von 500 ms bis 680 ms führte.
• Nach der Aktivierung von Smart Placement wurden – abgesehen von der einmaligen Weiterleitung der ersten Benutzeranfrage (ca. 150 ms) – alle DB-Abfragen in unter 1 ms verarbeitet. Dadurch hat sich die Antwortzeit weltweit auf ca. 100 ms bis 175 ms vereinheitlicht, unabhängig davon, aus welchem Land der Zugriff erfolgt.

Checkliste und Hinweise zur Verwendung von Smart Placement

Smart Placement ist nicht in jedem Fall die Universallösung. Die Funktion sollte passend zur Architektur des jeweiligen Dienstes eingesetzt werden.

1. Wann Smart Placement empfohlen wird (Empfohlen)

• Wenn Sie eine zentralisierte SQL/NoSQL-Datenbank in einer bestimmten Public-Cloud-Region (AWS, GCP, Azure, Ncloud etc.) betreiben
• Wenn innerhalb einer einzelnen API-Anfrage mehrere ausgehende HTTP-/DB-Abfragen durchgeführt werden
• Bei Laufzeit-Backends mit komplexen Beziehungsabfragen, wie z. B. GraphQL-API-Servern

2. Wann Smart Placement vermieden werden sollte (Vermeiden)

• Fokus auf Cloudflare Edge-Native Storage: Nutzung von global verteilten Speichern oder Edge-Datenbanken wie KV, D1, R2, Vectorize (in diesem Fall ist Default Placement in der Nähe des Benutzers deutlich schneller)
• Reine SSR/SSG statische HTML-Rendering-Seiten: Seiten, die HTML/CSS/Assets ohne DB-Abfrage zurückgeben

3. Kombination mit Hyperdrive

Wenn Sie PostgreSQL oder MySQL einsetzen, wird die Kombination aus Smart Placement + Cloudflare Hyperdrive dringend empfohlen. Hyperdrive verwaltet das Datenbank-Connection-Pooling und reduziert die Verbindungslatenz am Edge, während Smart Placement Verzögerungen zum Origin-Standort eliminiert – for eine maximale Edge-Datenbankperformance.

Fazit: Globale Servicequalität mit einer 1-Minute-Konfiguration revolutionieren

Beim Betrieb eines Dienstes für globale Benutzer ist die Latenz zwischen der Datenbank und Serverless-Funktionen einer der größten Faktoren, die die Benutzererfahrung (UX) und die Konversionsrate (Conversion Rate) beeinträchtigen.

Smart Placement und Smart Tiered Cache von Cloudflare Workers senken die globale P95-Latenz um über 80 % – ohne komplexe Multi-Regionen-Datenbankreplikation (Multi-region Replication) oder teure Standleitungen, sondern einfach durch das Hinzufügen von nur 3 Zeilen in der Konfigurationsdatei wrangler.jsonc.

"placement": {
  "mode": "smart"
}

Aktivieren Sie Smart Placement noch heute in Ihrem bestehenden Workers-Projekt und erleben Sie, wie die Echtzeit-Latenzgrafik im Dashboard drastisch nach unten fällt.

Ähnlicher Artikel: Weitere Informationen finden Sie im Observability-Optimierungsleitfaden unter Cloudflare Workers OpenTelemetry: OTLP-Kosten 90% senken.