← Cloudflare Workflows / workflows / reference

Limity

Limity, které platí pro vytváření, nasazování a spouštění Workflows, jsou podrobně popsány níže.

Mnohé limity jsou zděděny z limitů platných pro skripty Workers a jsou zdokumentovány v Limity Workers dokumentace.

Pokud potřebujete ve Workflows v JavaScriptu uchovat velký binární výstup z kroku, vraťte ReadableStream<Uint8Array>. Streamované výstupy se stále započítávají do limitu úložiště na instanci, proto velmi velké nebo dlouhodobě uchovávané artefakty ukládejte do externího úložiště, například R2 a v případě potřeby vrátit odkaz.

Instance, které jsou ve stavu waiting stavu, ať už prostřednictvím uspání pomocí step.sleep, čeká na opakování, nebo čeká na událost prostřednictvím step.waitForEvent, provede ne se započítávají do limitů souběžnosti. To znamená, že můžete mít současně miliony instancí Workflow, které spí nebo čekají na události, protože se počítají pouze aktivně running instance se započítávají do limitu 10,000 souběžných instancí. Pokud je však aktivně spuštěno 10,000 souběžných instancí, instance, která byla ve stavu waiting stavu budou zařazeny do fronty místo okamžitého pokračování. Když instance přejde ze stavu running na waiting, ostatní queued instance budou naplánovány (obvykle nejstarší instance v čekání, na základě nejlepší snahy). K tomuto přechodu stavu nemusí dojít, pokud je doba čekání velmi krátká.

Představte si například Workflow, který vykoná určitou práci, počká 30 dní a poté pokračuje další prací:

import {
	WorkflowEntrypoint,
	WorkflowStep,
	WorkflowEvent,
} from "cloudflare:workers";

type Env = {
	MY_WORKFLOW: Workflow;
};

export class MyWorkflow extends WorkflowEntrypoint<Env> {
	async run(event: WorkflowEvent<unknown>, step: WorkflowStep) {
		await step.do("initial work", async () => {
			let resp = await fetch("https://api.cloudflare.com/client/v4/ips");
			return await resp.json<any>();
		});

		await step.sleep("wait 30 days", "30 days");

		await step.do(
			"make a call to write that could maybe, just might, fail",
			{
				retries: {
					limit: 5,
					delay: "5 seconds",
					backoff: "exponential",
				},
				timeout: "15 minutes",
			},
			async () => {
				if (Math.random() > 0.5) {
					throw new Error("API call to $STORAGE_SYSTEM failed");
				}
			},
		);
	}
}

Pokud daná instance Workflow čeká 30 dní, přejde do stavu waiting stavu, což umožňuje jiným queued instance ke spuštění, pokud jsou dosaženy limity souběžnosti.

Na Workers Paid, instance Workflow vytvořené schedules může běžet až jednu hodinu na jedno spuštění cronu, aniž by spotřeboval slot souběžnosti Workflow.

Jakmile je tento rozpočet vyčerpán, instance se pozastaví a zařadí do běžné fronty souběžnosti. Pokračuje ve chvíli, kdy je k dispozici volný slot souběžnosti. Kvůli vyčerpání tohoto cron rozpočtu souběžnosti instance neselže, nedojde jí čas ani se neukončí.

Následující omezení platí pro Workflow schedules:

Každá instance Workflow standardně podporuje 10,000 kroků, ale v konfiguraci nástroje Wrangler lze tento limit zvýšit až na 25,000 kroků. Více informací najdete v Limity kroků Workflow s dalšími informacemi.

Workflows jsou skripty Workers a sdílejí stejné limity CPU na jedno volání stejně jako kterýkoli Worker. Upozorňujeme, že čas CPU je aktivní doba zpracování: nezahrnuje čas strávený čekáním na síťové požadavky, volání úložiště ani jiné běžné vstupně výstupní operace, které se do vašeho času CPU ani spotřeby výpočetního výkonu Workflows nezapočítávají.

Pokud váš Workflow překročí limit doby využití CPU, vyvolá následující chybu:

Error: Worker exceeded CPU time limit.

Zobrazí se jako exceededCpu v wrangler tail výsledky a jako exceededResources v Metriky Workers.

Maximální doba CPU na jedno spuštění Workflow je ve výchozím nastavení 30 sekund, lze ji ale zvýšit pro všechna spuštění patřící k dané definici Workflow nastavením limits.cpu_ms ve vaší konfiguraci Wrangler:

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

Chcete-li se dozvědět více o CPU čase a limitech, prostudujte dokumentaci Workers.

Subrequest je jakýkoli požadavek, který Workflow odešle buď na internetové zdroje pomocí Fetch API nebo požadavky na jiné služby Cloudflare, jako je R2, KV, nebo D1. Protože Workflows běží dlouhodobě a často provádějí mnoho volání externích služeb nebo Cloudflare API, mohou překročit výchozí limit subrequestů.

Pokud váš Workflow překročí limit počtu subrequestů, vyvolá následující chybu:

Error: Too many subrequests.

Zobrazí se jako exceededResources v Metriky Workers a jako exception v wrangler tail výsledky.

Maximální počet subrequestů na jednu instanci Workflow je ve výchozím nastavení 10,000 v plánech Workers Paid, ale lze jej zvýšit až na 10 milionů nastavením limits.subrequests ve vaší konfiguraci Wrangler:

{
	// ...rest of your configuration...
	"limits": {
		"subrequests": 10000000, // 10 million (maximum)
	},
	// ...rest of your configuration...
}

[limits]
subrequests = 10_000_000

Workers na bezplatném plánu mají limit 50 externích subrequestů a 1,000 subrequestů do služeb Cloudflare na jedno volání.

Další informace o limitech dílčích požadavků najdete prostudujte dokumentaci Workers.

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: