A Vercel 91 százalékkal csökkentette a CDN metaadat-lekérdezési idejét

Minden kérésnél útvonalat keres a CDN

A Vercelhez érkező minden kérés áthalad a vállalat CDN-jén, amely másodpercenként átlagosan több mint 80 millió útválasztási utasítást hajt végre. A rendszernek meg kell állapítania, hogy az adott útvonal létezik-e, és milyen tartalom vagy függvény szolgálja ki.

A beérkező útvonal nem mindig egyezik meg a kiszolgált tartalom útvonalával. A /blog/hello-world kérés például a dinamikus /blog/[slug] útvonalra oldódhat fel, egy React Server Component adata pedig a /blog/[slug].rsc útvonalra. A keretrendszerek a build során írják le ezeket a szabályokat, a Vercel pedig ezek alapján állítja elő a CDN által használt útválasztási metaadatokat.

A Vercel korábban minden célútvonal metaadatait külön objektumban tárolta, és minden lekérdezés külön töltötte le, illetve gyorsítótárazta az objektumot. Ez kisebb, ritkábban telepítő projekteknél megfelelően működött, nagy telepítéseknél viszont minden új kiadás új gyorsítótárkulcsokat hozott létre.

Az indexelt adatdarabok több útvonalat melegítenek be

Az új megoldásban a Vercel sok útvonal metaadatait úgynevezett shardokba, vagyis korlátozott méretű adatdarabokba csoportosította. Egy ilyen adatdarab betöltése több útvonal metaadatait helyezi a gyorsítótárba, így a későbbi lekérdezések újabb letöltés nélkül használhatják ezeket.

Minden shard indexet is tartalmaz. Ennek segítségével a CDN közvetlenül megtalálhatja a keresett útvonal metaadatát anélkül, hogy a teljes adatdarabot dekódolnia, kitömörítenie vagy feldolgoznia kellene. A rendszer bináris keresést használ, majd csak a megtalált JSON-értéket értelmezi. A Vercel JSONL-alapú elrendezést alkalmazott, amelyben a rendezett útvonalak és metaadataik váltakozó rekordokként szerepelnek.

A vállalat kezdetben több megabájtos shardokkal kísérletezett, de az éles forgalomban ezek túl lassan töltődtek be a folyamatok helyi gyorsítótárának hiányában. A túl kicsi adatdarabok eközben túl sok régiós gyorsítótárhiányt okoztak. A tesztek alapján körülbelül 200 KB-os shardok adták a megfelelő egyensúlyt.

91 százalékkal csökkent a P99 késleltetés

A Vercel 2026. augusztus 5. és 12. között, éles forgalmon mérte az új megoldást. Az útvonalankénti metaadat-lekérdezések 215,8 ezredmásodperces P99 késleltetése indexelt shardokkal 19,1 ezredmásodpercre esett, ami 91 százalékos csökkenés. Az átlagos késleltetés 8,59 ezredmásodpercről 1,81 ezredmásodpercre, 79 százalékkal mérséklődött. A szórás 44,9 ezredmásodpercről 19 ezredmásodpercre csökkent.

A bevezetést a vállalat először offline tesztekkel, majd úgynevezett shadow mode-ban ellenőrizte. Ebben a módban a rendszer véletlenszerűen kiválasztott kéréseknél párhuzamosan futtatta az új és a régi lekérdezést, de továbbra is a régi eredményt szolgálta ki. A tesztelés több héten át zajlott, az eltérések rendkívül ritkák voltak.

Az egyik eltérés egy régi kódolási hibához kapcsolódott, amely csak akkor jelent meg, amikor egy emoji két RFC 2047 kódolt szó között oszlott meg. Az új formátum az útvonalakat közvetlenül UTF-8-ban tárolja.

A telepítések is gyorsultak

Miután az új shardok éles forgalmat szolgáltak ki, a Vercel eltávolította a buildfolyamatból a korábban szükséges, de már feleslegessé vált lépéseket. Az útvonalankénti metaadatok feltöltésének kihagyása körülbelül 9,7 másodpercet takarít meg, az útvonalcsoport-metaadatok manifestbe írása további 4,5 másodpercet, az üresen maradt fájlok feltöltésének elhagyása pedig 2,4 másodpercet.

Ez együtt nagyjából 16,6 másodperc megtakarítást jelent. A Vercel szerint a telepítési lépés minden telepítésnél körülbelül 10 százalékkal gyorsabb, a metaadatokban gazdag telepítéseknél pedig a becslés közelebb van a 25 százalékhoz. A változás így a felhasználók számára gyorsabb útvonal-feloldást és rövidebb telepítési folyamatot jelent.