← Cloudflare Workers / workers / platform

Лимиты

¹ Если вы достигли этого лимита, рассмотрите использование Workers for Platforms.

Лимиты размера тела запроса зависят от плана вашего аккаунта Cloudflare, а не от плана Workers. Запросы, превышающие эти лимиты, возвращают 413 Request entity too large ошибка.

Клиенты Enterprise могут обратиться к своей команде по работе с аккаунтом или Служба поддержки Cloudflare для увеличения лимита размера тела запроса.

Cloudflare не ограничивает размер тела ответа. Ограничения кеша CDN применяются: 512 МБ для планов Free, Pro и Business, и 5 ГБ для Enterprise.

Время CPU измеряет, сколько времени CPU тратит на выполнение кода вашего Worker. Ожидание сетевых запросов (например, fetch() вызовы, чтение из KV или запросы к базе данных) не не учитываются во времени CPU.

Большинство Workers потребляют очень мало процессорного времени. В среднем Worker расходует около 2.2 мс на запрос. Более тяжелые нагрузки, связанные с аутентификацией, серверным рендерингом или разбором больших объемов данных, обычно занимают 10-20 мс.

Каждый изолят обладает встроенной гибкостью для случаев, когда ваш Worker изредка превышает установленный лимит. Если Worker начинает регулярно достигать лимита, его выполнение будет прервано в соответствии с установленным лимитом.

Когда Worker превышает лимит времени CPU, Cloudflare возвращает Ошибка 1102 клиенту с сообщением Worker exceeded resource limits. В дашборде это отображается как Exceeded CPU Time Limits в разделе Метрики > Ошибки > Статусы вызовов. В Analytics и Logpush результат вызова обозначается как exceededCpu.

Чтобы устранить ошибку превышения лимита процессорного времени:

1. Увеличьте лимит CPU-времени : на платном плане Workers Paid можно увеличить лимит по умолчанию с 30 секунд до 5 минут (300,000 мс). Это настраивается в конфигурации Wrangler или в дашборде.
2. Оптимизируйте свой код : используйте Профилирование CPU в DevTools чтобы выявить участки кода с высокой нагрузкой на CPU.
3. Вынос задач за пределы запроса : перенесите ресурсоёмкие вычисления в Durable Objects или обрабатывать данные меньшими порциями в нескольких запросах.

На плане Workers Paid можно увеличить максимальное время CPU с 30 секунд по умолчанию до 5 минут (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

Это также можно изменить в панели управления: перейдите в Workers & Pages > выберите Worker > Настройки > настройте лимит времени CPU.

• Workers Logs : процессорное время и общее время выполнения отображаются в журнал вызовов.
• Tail Workers / Logpush : процессорное время и общее время выполнения отображаются на верхнем уровне объект Workers Trace Events.
• DevTools : используйте Профилирование CPU в DevTools локально, чтобы найти ресурсоёмкие по CPU участки вашего кода.

Каждый изолят может потреблять до 128 МБ памяти, включая кучу JavaScript и WebAssembly выделений памяти. Этот лимит действует на изолят, а не на вызов. Один изолят может обрабатывать множество параллельных запросов.

Когда изолят превышает 128 МБ, среда выполнения Workers дает завершиться уже выполняющимся запросам и создает новый изолят для последующих запросов. При экстремально высокой нагрузке среда выполнения может отменять часть входящих запросов для сохранения стабильности.

Когда Worker превышает лимит памяти, Cloudflare возвращает Ошибка 1102 клиенту с сообщением Worker exceeded resource limits. В дашборде это отображается как Exceeded Memory в разделе Метрики > Ошибки > Статусы вызовов. В Analytics и Logpush результат вызова обозначается как exceededMemory.

Вы также можете увидеть ошибку выполнения Memory limit would be exceeded before EOF при попытке буферизовать тело ответа, превышающее лимит.

Чтобы устранить ошибку превышения лимита памяти:

1. Потоковая передача тела запроса и ответа : используйте TransformStream или node:stream вместо буферизации всей полезной нагрузки в памяти.
2. Избегайте больших объектов в памяти : храните большие объёмы данных в KV, R2, или D1 вместо хранения в памяти Worker.
3. Профилирование использования памяти : используйте профилирование памяти с помощью DevTools локально, чтобы найти утечки и участки с большим потреблением памяти.

Чтобы просмотреть ошибки памяти в дашборде:

1. Перейдите в Workers & Pages.

   Перейдите в Workers & Pages ↗

2. Выберите Worker, который хотите изучить.

3. В разделе Метрики, выберите Ошибки > Статусы вызовов и изучить Превышен лимит памяти.

Duration измеряет фактическое время (wall-clock time) от начала до конца вызова Worker.

Жёсткого ограничения по длительности для Workers, запускаемых по HTTP, не существует. Пока клиент остаётся подключённым, Worker может продолжать обработку, выполнять подзапросы и передавать тело ответа потоком. Когда клиент отключается или ответ завершён, задачи, связанные с этим запросом, могут быть отменены. Используйте ctx.waitUntil() чтобы выполнить работу после отправки ответа. waitUntil() может продлевать выполнение до 30 секунд после отправки ответа или отключения клиента.

Workers автоматически масштабируются по всей глобальной сети Cloudflare. Общего ограничения на количество запросов в секунду не существует.

Аккаунты на тарифе Workers Free имеют дневной лимит в 100,000 запросов, который сбрасывается в полночь UTC. Когда Worker превышает этот лимит, Cloudflare возвращает Ошибка 1027.

Режим отказа можно настроить, переключив соответствующий маршрут.

Subrequest представляет собой любой запрос, который Worker отправляет с помощью Fetch API или к сервисам Cloudflare, таким как R2, KV, или D1.

Каждый подзапрос в цепочке перенаправлений учитывается в этом лимите. Общее количество подзапросов может превышать количество fetch() вызовов в вашем коде. Изменить лимит подзапросов для Worker можно с помощью limits конфигурация в конфигурационном файле Wrangler.

Фиксированного лимита времени для отдельных подзапросов не установлено. Пока клиент остаётся подключённым, Worker может продолжать выполнять подзапросы. Когда клиент отключается или ответ завершён, незавершённая работа может быть отменена, если только она не передана в ctx.waitUntil(), что позволяет продлить выполнение до 30 секунд.

Используйте Service Bindings чтобы отправлять запросы от одного Worker к другому в пределах вашего аккаунта, не выходя в интернет.

Использование глобального fetch() чтобы вызвать другой Worker в том же зона без привязок служб завершается ошибкой. Workers принимают запросы, отправленные на Custom Domain.

При каждом вызове Worker может быть до шести соединений, одновременно ожидающих заголовки ответа. Следующие вызовы API учитываются в этом лимите, пока устанавливается исходное соединение и сервер ещё не ответил:

• fetch() метод объекта Fetch API
• get(), put(), list(), а также delete() методы объекты пространства имён Workers KV
• put(), match(), а также delete() методы Объекты кеша
• list(), get(), put(), delete(), а также head() методы R2
• send() и sendBatch() методы Queues
• Открытие TCP-сокета с помощью connect() API

Исходящие WebSocket соединения также учитываются в этом лимите.

Как только для соединения приходят заголовки ответа, оно больше не учитывается в лимите шести соединений. Это означает, что Worker может одновременно держать открытыми много соединений, если не более шести из них одновременно находятся в начальной фазе «ожидания заголовков». Если предпринимается попытка седьмого соединения, пока шесть уже ожидают заголовков, оно ставится в очередь, пока одно из существующих соединений не получит заголовки ответа.

Если вы используете fetch() но тело ответа вам не нужно, вызов 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();
}

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();
}

Большие сборки Worker могут увеличивать время запуска. Чтобы проверить размер сжатой сборки:

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

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

Чтобы уменьшить размер Worker:

• Удалите ненужные зависимости и пакеты.
• Храните файлы конфигурации, статические ресурсы и двоичные данные в KV, R2, D1, или Workers Static Assets вместо их сборки в бандл.
• Разделите функциональность между несколькими Workers с помощью Service bindings.

Worker должен разобрать и выполнить свою глобальную область видимости (код верхнего уровня вне обработчиков) в течение 1 секунды. Более крупные бандлы и затратный по времени код инициализации в глобальной области увеличивают время запуска.

Если платформа отклоняет развёртывание из-за превышения Worker лимита времени запуска, проверка возвращает ошибку Script startup exceeded CPU time limit (код ошибки 10021). Wrangler автоматически создаёт CPU-профиль, который можно импортировать в Chrome DevTools или открыть в VS Code. См. wrangler check startup для дополнительных сведений.

Чтобы измерить время запуска, выполните npx wrangler@latest deploy или npx wrangler@latest versions upload. Wrangler сообщает startup_time_ms в выводе.

Чтобы сократить время запуска, избегайте ресурсоёмких операций в глобальной области видимости. Перенесите логику инициализации в обработчик или на этап сборки. Например, генерация или обработка большой схемы на верхнем уровне часто становится причиной превышения этого лимита.

Если вам нужно больше 500 Workers, рассмотрите использование Workers for Platforms.

Когда вы запускаете удаленная разработка сессию с помощью --remote флаг, Cloudflare устанавливает ограничение в 50 маршрутов на зону. Quick Editor в панели управления Cloudflare также использует wrangler dev --remote, поэтому действует то же ограничение.

Если в вашей зоне больше 50 маршрутов, вы не сможете запустить удалённую сессию, пока не удалите часть маршрутов и не уложитесь в лимит.

Если вам нужно больше 1,000 маршрутов или 1,000 зон с маршрутизацией на один Worker, рассмотрите использование Workers for Platforms. Если вам нужно больше 100 пользовательских доменов на зону, рассмотрите использование wildcard маршрут.

Вызовы на запрос означают количество put(), match(), или delete() вызовов Cache API на запрос. Эта квота общая с подзапросами (fetch()).

Этот лимит распространяется на все данные, отправляемые через console.log() инструкции, исключения, метаданные запроса и заголовки для одного запроса. После превышения этого лимита система не записывает дополнительный контекст для этого запроса в логах, tail logs или Tail Workers.

См. документация Workers Trace Event Logpush с ограничениями на поля, отправляемые в места назначения Logpush.

См. Документация Image Resizing с ограничениями, которые действуют при использовании Image Resizing с Workers.

Если ваш Worker находится на плане Unbound, лимиты совпадают с планом Workers Paid.

Если ваш Worker находится на плане Bundled, лимиты совпадают с планом Workers Paid, за следующими исключениями:

Workers на тарифе Bundled не имеют ограничений по длительности для Cron Triggers, Durable Object Alarms, или Потребители Queue.

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

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

• Лимиты KV
• Лимиты Durable Object
• Лимиты Queues
• справочник по ошибкам Workers