Cache és teljesítmény

18.1A három cache-réteg — ne keverd össze őket

Ez a leggyakoribb zavarforrás, ezért kezdjük ezzel. A Workers körül három különböző cache-mechanizmus van, más-más viselkedéssel:

Workers Caching bekapcsolása

{
  "cache": { "enabled": true }
}

Innentől a Worker válaszainak cache-elhetőségét a szokásos Cache-Control header vezérli — vagyis ugyanaz a mechanizmus, amit HTTP-ből ismersz, csak most a saját válaszaidra alkalmazod:

return new Response(body, {
  headers: {
    // 5 percig friss; utána 1 óráig kiadható a régi, míg a háttérben frissül
    "Cache-Control": "public, max-age=300, stale-while-revalidate=3600",
  },
});

18.2A multitenant cache-kulcs — itt lehet nagyot hibázni

Multitenant SaaS-ban ugyanaz az URL (/api/dashboard) tenantonként és felhasználónként más tartalmat ad. Ha a cache-kulcs csak az URL, akkor A tenant válasza kimehet B tenantnak — ez a legdurvább hibaosztály, ami cache-eléssel elkövethető.

Négy megközelítés, növekvő biztonsággal:

18.3Mit cache-elj egy SaaS-ban? — a rétegek

Az alkalmazás-szintű cache (KV-ben) az, amit a leggyakrabban fogsz használni, mert a legtöbb SaaS-tartalom nem HTTP-cache-elhető, viszont a mögötte lévő számítás igen:

export async function cached<T>(
  event, key: string, ttl: number, produce: () => Promise<T>
): Promise<T> {
  const { env } = event.context.cloudflare;
  const tenantId = event.context.tenantId;          // 17. modul middleware-ből
  const ns = `v1:${tenantId}:${key}`;                // verzió + bérlő a kulcsban!

  const hit = await env.CACHE.get(ns, { type: "json" });
  if (hit) return hit as T;

  const fresh = await produce();
  // nem várunk rá: a válasz mehet, az írás a háttérben fut (2. modul)
  event.context.cloudflare.context.waitUntil(
    env.CACHE.put(ns, JSON.stringify(fresh), { expirationTtl: ttl })
  );
  return fresh;
}

Két részlet, ami sokat számít: a kulcsban ott a verzió-prefix (v1:) — ha a válasz szerkezete változik, a prefix emelésével az egész cache-t érvényteleníted deploy nélkül; és a bérlő — lásd 18.2.

18.4Invalidálás: a nehezebbik fele

„A számítástechnika két nehéz problémája: a cache-invalidálás és az elnevezés." A gyakorlati eszköztárad:

Az írás-utáni invalidálás mintája

// riport frissítése után: a tenant összes riport-cache-ét eldobjuk
export default defineEventHandler(async (event) => {
  await updateReport(event, data);

  const { env } = event.context.cloudflare;
  const tenantId = event.context.tenantId;

  // KV: a verziószámot emeljük tenantonként — az összes régi kulcs elárvul
  await env.CACHE.put(`ver:${tenantId}`, String(Date.now()));
  return { ok: true };
});

A „verzió-token" minta gyakran jobb, mint a törölgetés: nem kell tudnod, milyen kulcsok léteznek — egy szám emelésével az összes régi bejegyzés érvénytelenné válik, és a TTL magától kitakarítja őket.

18.5Teljesítmény a cache-en túl

Smart Placement — ha sok a DB-kör

Az 5b. modulban már felmerült: ha egy kérés sok lekérdezést lő ugyanarra az adatbázisra, a Worker futtatása a felhasználó mellett rosszabb, mint az adatbázis mellett — mert minden query átmegy az óceánon. A Smart Placement ilyenkor magát a Workert helyezi át:

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

Mikor segít: több (3-4+) egymás utáni DB-hívás kérésenként. Mikor nem: ha kérésenként egy lekérdezés van — akkor a teljes körút ugyanannyi, akárhol fut a Worker (a doksi ezt külön kiemeli). Mérd meg, ne tippelj.

A latencia-lánc: mit optimalizálj sorrendben?

1. Szüntesd meg a sorozatos (soros) hívásokat. Ez a leggyakoribb valódi ok. Ha három független lekérdezésed van, ne egymás után várd meg őket:

   // ❌ 3 × 80 ms = 240 ms
   const a = await q1(); const b = await q2(); const c = await q3();
   // ✅ ~80 ms
   const [a, b, c] = await Promise.all([q1(), q2(), q3()]);

   (Vigyázz a 6 egyidejű kimenő kapcsolat korlátjára — 2. modul.)
2. Kevesebb kör a DB-hez: D1-nél batch() (5. modul), Postgresnél kevesebb, jobban megírt query — a Hyperdrive cache is itt segít (4. modul).
3. Streaming SSR:
4. Bundle-méret és startup: a Worker indulási ideje (1 s limit, 2. modul) a top-level importoktól függ. Nehéz könyvtárat importálj lustán, a startup-profilozóval mérj (11. modul).
5. CPU-idő: a 9. modul versionönkénti percentilisei mutatják meg, hol drága a kód; a DevTools CPU-profil pedig, hogy min belül.

18.6Ellenőrizd magad