← Cloudflare Workflows / workflows / reference

Лимиты

Ниже перечислены ограничения, которые действуют при разработке, развёртывании и выполнении Workflows.

Многие ограничения унаследованы от скриптов Workers и описаны в лимиты Workers документация.

В JavaScript Workflows, если вам нужно сохранить большой бинарный результат шага, возвращайте ReadableStream<Uint8Array>. Потоковые выходные данные по-прежнему учитываются в лимите хранилища на экземпляр, поэтому очень большие или долгоживущие артефакты стоит хранить во внешнем хранилище, например R2 и возвращать ссылку, когда это уместно.

Экземпляры, которые находятся в waiting состояние: либо переход в спящий режим через step.sleep, ожидает повторной попытки или ожидает событие через step.waitForEvent : выполните не засчитываются в лимиты параллелизма. Это означает, что могут одновременно существовать миллионы экземпляров Workflow, находящихся в спящем режиме или ожидающих событий, поскольку лимитам параллелизма подлежат только активно running инстансы учитываются в лимите 10 000 одновременно выполняемых инстансов. Однако если уже выполняется 10 000 инстансов одновременно, инстанс, который находится в состоянии waiting будут поставлены в очередь вместо немедленного возобновления. Когда экземпляр переходит из состояния running к waiting, другие queued инстансы будут запланированы (как правило, это самый старый инстанс в очереди, по мере возможности). Этот переход состояния может не произойти, если время ожидания очень короткое.

Например, рассмотрим Workflow, который выполняет часть работы, ждет 30 дней, а затем продолжает выполнение:

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");
				}
			},
		);
	}
}

Когда экземпляр Workflow ожидает в течение 30 дней, он переходит в waiting состояние, позволяя другим queued инстансов для запуска, если достигнуты лимиты одновременного выполнения.

На Workers Paid, экземпляры Workflow, созданные schedules может выполняться до одного часа за одно срабатывание cron, не занимая слот параллелизма Workflow.

После исчерпания этого бюджета экземпляр приостанавливается и переходит в обычную очередь с учетом лимита параллелизма. Он возобновляет работу, когда освобождается слот параллелизма. Экземпляр не завершается ошибкой, не истекает по таймауту и не прерывается из-за использования этого бюджета параллелизма cron.

Следующие ограничения применяются к Workflow schedules:

Каждый экземпляр Workflow по умолчанию поддерживает 10,000 шагов, но это значение можно увеличить до 25,000 шагов в конфигурации Wrangler. См. Лимиты шагов Workflow, где это описано подробнее.

Workflows являются скриптами Workers и используют одинаковые лимиты CPU на один вызов как и любые Workers. Обратите внимание: процессорное время означает время активной обработки, а не время ожидания сетевых запросов, обращений к хранилищу или других операций ввода-вывода, которое не учитывается в процессорном времени или потреблении вычислительных ресурсов Workflows.

Если ваш Workflow превысит лимит времени CPU, он выдаст следующую ошибку:

Error: Worker exceeded CPU time limit.

Это будет отображаться как exceededCpu в wrangler tail результатов, а также как exceededResources в Workers metrics.

По умолчанию максимальное время CPU на один вызов Workflow составляет 30 секунд, но его можно увеличить для всех вызовов, связанных с определением Workflow, задав limits.cpu_ms в конфигурации Wrangler:

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

[limits]
cpu_ms = 300_000

Подробнее о процессорном времени и лимитах см. ознакомьтесь с документацией Workers.

Подзапросом называется любой запрос, который Workflow отправляет либо к интернет-ресурсам с использованием Fetch API или запросы к другим сервисам Cloudflare, например R2, KV, или D1. Поскольку Workflows выполняются долго и часто отправляют много запросов к внешним сервисам или API Cloudflare, они могут превысить лимит подзапросов по умолчанию.

Если ваш Workflow превысит лимит подзапросов, он выдаст следующую ошибку:

Error: Too many subrequests.

Это будет отображаться как exceededResources в Workers metrics и как exception в wrangler tail результатов.

По умолчанию максимальное количество подзапросов на один экземпляр Workflow составляет 10,000 на плане Workers Paid, но его можно увеличить до 10 миллионов, задав limits.subrequests в конфигурации Wrangler:

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

[limits]
subrequests = 10_000_000

На тарифе Free для Workers по-прежнему действует ограничение: 50 внешних подзапросов и 1,000 подзапросов к сервисам Cloudflare за один вызов.

Подробнее об ограничениях на количество подзапросов см. в ознакомьтесь с документацией Workers.

Астрономическое время (также называемое wall-clock time) обозначает общее время, прошедшее от начала до конца вызова, включая время ожидания сетевых запросов, операций ввода-вывода и других асинхронных операций. Это отличается от Процессорное время, который измеряет только время, которое CPU активно тратит на выполнение вашего кода.

В следующей таблице приведены ограничения по фактическому времени выполнения для разных типов вызовов Worker на платформе для разработчиков: