← Cloudflare Workers / workers / platform

Limity

¹ Pokud tento limit dosáhnete, zvažte použití Workers for Platforms.

Limity velikosti těla požadavku závisí na vašem plánu účtu Cloudflare, nikoli na plánu Workers. Požadavky, které tyto limity překročí, vrátí 413 Request entity too large chyba.

Zákazníci s plánem Enterprise mohou kontaktovat svůj tým pro správu účtu nebo Cloudflare Support pro vyšší limit velikosti těla požadavku.

Cloudflare nevynucuje limity velikosti těla odpovědi. Limity mezipaměti CDN platí: 512 MB pro plány Free, Pro a Business a 5 GB pro Enterprise.

Čas CPU měří, jak dlouho CPU tráví prováděním kódu vašeho Workeru. Čekání na síťové požadavky (například fetch() volání, čtení z KV nebo databázové dotazy) nezajišťuje ne se započítávají do doby CPU.

Většina Workers spotřebuje jen velmi málo CPU času. Průměrný Worker využije přibližně 2.2 ms na požadavek. Náročnější úlohy, jako je autentizace, server-side rendering nebo zpracování velkých payloadů, obvykle spotřebují 10-20 ms.

Každý izolát má určitou vestavěnou flexibilitu pro případy, kdy váš Worker příležitostně překročí nastavený limit. Pokud váš Worker začne limit překračovat trvale, jeho spuštění bude ukončeno podle nastaveného limitu.

Když Worker překročí limit doby CPU, Cloudflare vrátí Chyba 1102 klientovi se zprávou Worker exceeded resource limits. V dashboardu se to zobrazuje jako Exceeded CPU Time Limits v části Metriky > Chyby > Invocation Statuses. V Analytics a Logpush je výsledek volání exceededCpu.

Chcete-li vyřešit chybu limitu doby CPU:

1. Zvyšte limit CPU času : v plánu Workers Paid můžete limit zvýšit z výchozích 30 sekund až na 5 minut (300,000 ms). Nastavte to v konfiguraci Wrangleru nebo na dashboardu.
2. Optimalizujte svůj kód : použijte Profilování CPU pomocí DevTools k identifikaci částí kódu náročných na CPU.
3. Odložení práce : přesuňte náročné výpočty do Durable Objects nebo zpracovávat data v menších částech napříč více požadavky.

V plánu Workers Paid můžete zvýšit maximální dobu CPU z výchozích 30 sekund až na 5 minut (300,000 ms).

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // default is 30000 (30 seconds)
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

Toto můžete také změnit v dashboardu: přejděte na Workers & Pages > vyberte svůj Worker > Nastavení > upravte limit CPU času.

• Workers Logs : CPU time a wall time se zobrazují v log volání.
• Tail Workers / Logpush : CPU time a wall time se zobrazují na nejvyšší úrovni objekt Workers Trace Events.
• DevTools : použijte Profilování CPU pomocí DevTools lokálně, abyste ve svém kódu identifikovali části náročné na CPU.

Každý izolát může spotřebovat až 128 MB paměti, včetně haldy JavaScriptu a WebAssembly alokace. Tento limit platí na izolát, nikoli na jedno volání. Jeden izolát dokáže zpracovat mnoho souběžných požadavků.

Když izolát překročí 128 MB, runtime prostředí Workers nechá rozpracované požadavky doběhnout a pro další požadavky vytvoří nový izolát. Při extrémně vysoké zátěži může runtime některé příchozí požadavky zrušit, aby zachoval stabilitu.

Když Worker překročí limit paměti, Cloudflare vrátí Chyba 1102 klientovi se zprávou Worker exceeded resource limits. V dashboardu se to zobrazuje jako Exceeded Memory v části Metriky > Chyby > Invocation Statuses. V Analytics a Logpush je výsledek volání exceededMemory.

Také se vám může zobrazit chyba za běhu Memory limit would be exceeded before EOF při pokusu o bufferování těla odpovědi, které přesahuje limit.

Chcete-li vyřešit chybu limitu paměti:

1. Streamování těl požadavků a odpovědí : použijte TransformStream nebo node:stream místo ukládání celého obsahu do paměti.
2. Vyhněte se velkým objektům v paměti : ukládejte velká data do KV, R2, nebo D1 místo jejich uchovávání v paměti Workeru.
3. Profilování využití paměti : použijte profilování paměti pomocí DevTools lokálně, abyste identifikovali úniky paměti a alokace s vysokou spotřebou paměti.

Chcete-li zobrazit chyby paměti v dashboardu:

1. Přejděte na Workers & Pages.

   Přejděte na Workers & Pages ↗

2. Vyberte Worker, který chcete prozkoumat.

3. V části Metriky, vyberte Chyby > Invocation Statuses a prozkoumejte Překročená paměť.

Duration měří reálný čas od začátku do konce vyvolání Workeru.

Pro Workers spouštěné přes HTTP neexistuje pevný limit doby trvání. Dokud zůstává klient připojen, může Worker pokračovat ve zpracování, vytváření dílčích požadavků a streamování těla odpovědi. Jakmile se klient odpojí nebo je odpověď dokončena, mohou být úkoly spojené s daným požadavkem zrušeny. Použijte ctx.waitUntil() pro provedení práce po odeslání odpovědi. waitUntil() může prodloužit běh až o 30 sekund po odeslání odpovědi nebo po odpojení klienta.

Workers se automaticky škálují v rámci celé globální sítě Cloudflare. Obecný limit počtu požadavků za sekundu neexistuje.

Účty v plánu Workers Free mají denní limit 100,000 požadavků, který se resetuje o půlnoci UTC. Pokud Worker tento limit překročí, Cloudflare vrátí Chyba 1027.

Fail mode můžete nakonfigurovat přepnutím odpovídajícího trasa.

Subrequest je jakýkoli požadavek, který Worker odešle pomocí Fetch API nebo ke službám Cloudflare, jako je R2, KV, nebo D1.

Každý subrequest v řetězci přesměrování se počítá do tohoto limitu. Celkový počet subrequestů může přesáhnout počet fetch() volání ve vašem kódu. Limit subrequestů na Worker můžete změnit pomocí limits konfigurace ve vašem konfiguračním souboru Wrangler.

Pro jednotlivé dílčí požadavky není stanoven žádný časový limit. Dokud zůstává klient připojen, může Worker pokračovat ve vytváření dílčích požadavků. Jakmile se klient odpojí nebo je odpověď dokončena, může být nedokončená práce zrušena, pokud nebyla předána ctx.waitUntil(), které mohou prodloužit provádění až o 30 sekund.

Použijte Service Bindings pro odesílání požadavků z jednoho Workeru do druhého v rámci vašeho účtu bez nutnosti procházet internetem.

Použití globálního fetch() pro volání jiného Workeru na stejném zóna bez service bindings selže. Workers přijímají požadavky odeslané na Custom Domain.

Každé volání Workeru může mít současně až šest připojení čekajících na hlavičky odpovědi. Do tohoto limitu se počítají následující volání API, dokud probíhá navazování počátečního připojení a server ještě neodpověděl:

• fetch() metoda v rámci Fetch API
• get(), put(), list(), a delete() metody Objekty jmenného prostoru Workers KV
• put(), match(), a delete() metody Objekty mezipaměti
• list(), get(), put(), delete(), a head() metody R2
• send() a sendBatch() metody Queues
• Otevření TCP socketu pomocí connect() API

Do tohoto limitu se započítávají i odchozí připojení WebSocket.

Jakmile pro dané spojení dorazí hlavičky odpovědi, přestane se počítat do limitu šesti spojení. To znamená, že Worker může mít současně otevřených mnoho spojení, pokud jich není více než šest zároveň ve fázi "waiting for headers". Pokud se pokusí navázat sedmé spojení, zatímco šest již čeká na hlavičky, zařadí se do fronty, dokud jedno z existujících spojení nepřijme své hlavičky odpovědi.

Pokud používáte fetch() ale nepotřebujete tělo odpovědi, volání response.body.cancel() je stále dobrým zvykem uvolnit paměť:

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

Větší balíčky Workeru mohou ovlivnit dobu spuštění. Velikost komprimovaného balíčku zjistíte takto:

wrangler deploy --outdir bundled/ --dry-run

# Output will resemble the below:
Total Upload: 259.61 KiB / gzip: 47.23 KiB

Chcete-li zmenšit velikost Workeru:

• Odeberte nepotřebné závislosti a balíčky.
• Ukládejte konfigurační soubory, statická aktiva a binární data do KV, R2, D1, nebo Workers Static Assets místo jejich sloučení do balíčku.
• Rozdělte funkčnost mezi více Workerů pomocí Service bindings.

Worker musí zpracovat a spustit svůj globální rozsah (kód nejvyšší úrovně mimo handlery) do 1 sekundy. Větší bundly a nákladná inicializace v globálním rozsahu prodlužují dobu spuštění.

Když platforma odmítne nasazení, protože Worker překročí limit doby spuštění, ověření vrátí chybu Script startup exceeded CPU time limit (chybový kód 10021). Wrangler automaticky vygeneruje profil CPU, který můžete importovat do Chrome DevTools nebo otevřít ve VS Code. Viz wrangler check startup pro další podrobnosti.

Chcete-li změřit dobu spuštění, spusťte npx wrangler@latest deploy nebo npx wrangler@latest versions upload. Wrangler hlásí startup_time_ms ve výstupu.

Chcete-li zkrátit dobu spuštění, vyhněte se náročným operacím v globálním rozsahu. Přesuňte inicializační logiku do svého handleru nebo do doby sestavení. Generování nebo zpracování velkého schématu na nejvyšší úrovni je například častou příčinou překročení tohoto limitu.

Pokud potřebujete více než 500 Workerů, zvažte použití Workers for Platforms.

Když spustíte vzdálený vývoj relaci pomocí --remote příznak, Cloudflare vynucuje limit 50 tras na zónu. Quick Editor v Cloudflare dashboardu rovněž používá wrangler dev --remote, takže platí stejný limit.

Pokud má vaše zóna více než 50 tras, nemůžete spustit vzdálenou relaci, dokud počet tras nesnížíte pod tento limit.

Pokud potřebujete více než 1,000 tras nebo 1,000 směrovaných zón na Worker, zvažte použití Workers for Platforms. Pokud potřebujete více než 100 vlastních domén na zónu, zvažte použití zástupné trasa.

Volání na požadavek je počet put(), match(), nebo delete() volání Cache API na požadavek. Tento limit sdílí stejnou kvótu jako subrequesty (fetch()).

Tento limit se vztahuje na všechna data odeslaná pomocí console.log() příkazů, výjimek, metadat requestu a hlaviček pro jeden request. Po překročení tohoto limitu systém pro daný request již nezaznamenává další kontext v lozích, tail lozích ani Tail Workers.

Viz Dokumentace Workers Trace Event Logpush pro limity polí odesílaných do cílů Logpush.

Viz Dokumentace ke změně velikosti obrázků pro limity platné při použití Image Resizing s Workers.

Pokud je váš Worker na plánu Unbound, limity odpovídají plánu Workers Paid.

Pokud je váš Worker na plánu Bundled, limity odpovídají plánu Workers Paid s těmito výjimkami:

Workers na plánu Bundled nemají žádné časové limity pro Cron Triggers, Durable Object Alarms, nebo Queue Consumers.

Reálný čas (anglicky též "wall-clock time") představuje celkovou dobu od začátku do konce vyvolání, včetně času stráveného čekáním na síťové požadavky, I/O operace a další asynchronní operace. Liší se od Čas CPU, které měří pouze čas, který CPU stráví aktivním prováděním vašeho kódu.

Následující tabulka shrnuje limity reálného času pro různé typy vyvolání Workeru v rámci vývojářské platformy:

• Limity KV
• Limity Durable Object
• Limity Queues
• Referenční přehled chyb Workers