← Cloudflare Queues / queues / platform

Лимиты

Возможность	Лимит
Queues	10,000 на аккаунт
Размер сообщения	128 KB ¹
Повторные попытки сообщений	100
Максимальный размер пакета потребителя	100 сообщений
Максимальное количество сообщений на `sendBatch` вызов	100 (или 256KB в общей сложности)
Максимальное время ожидания пакета	60 секунд
Пропускная способность сообщений на очередь	5,000 сообщений в секунду ²
Период хранения сообщений ³	Настраивается до 14 дней.
Размер бэклога на очередь ⁴	25GB
Параллельные вызовы потребителя	250 ^{только push}
Длительность потребителя (реальное время)	15 минут ⁵
Время CPU потребителя	Настраивается до 5 минут
`visibilityTimeout` (pull-очереди)	12 часов
`delaySeconds` (при отправке или повторной попытке)	24 часа

¹ 1 KB считается равным 1000 байт. Сообщения могут включать до ~100 байт внутренних метаданных, которые учитываются в общем лимите размера сообщения.

² Превышение максимальной пропускной способности сообщений приведёт к тому, что send() и sendBatch() методов выбросить исключение с Too Many Requests ошибку, пока производитель не опустится ниже лимита.

³ Сообщения в очереди, достигшие максимального срока хранения, удаляются из очереди. Queues не удаляет сообщения в той же очереди, которые не достигли этого лимита.

⁴ Отдельные очереди, достигшие этого лимита, получат Storage Limit Exceeded ошибку при вызове send() или sendBatch() для очереди.

⁵ См. лимиты Workers.

Увеличение лимитов CPU для Worker-потребителя очереди

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

По умолчанию максимальное время CPU на один вызов Worker-потребителя составляет 30 секунд, но его можно увеличить, задав 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.

Лимиты астрономического времени по типу вызова

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

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

Тип вызова	Лимит астрономического времени	Подробности
Входящий HTTP-запрос	Без ограничений	Жёсткое ограничение отсутствует, пока клиент остаётся подключённым. Worker, который продолжает передавать тело ответа потоком, остаётся активным. `waitUntil()` продлевает выполнение до 30 секунд после ответа или отключения.
Cron Triggers	15 минут	Для запланированных Workers максимальное время выполнения составляет 15 минут на один вызов.
Потребители Queue	15 минут	Максимальное время выполнения каждого вызова потребителя составляет 15 минут.
Обработчики alarm Durable Object	15 минут	Вызовы alarm handler выполняются не более 15 минут.
Durable Objects (RPC / HTTP)	Без ограничений	Жёсткое ограничение отсутствует, пока вызывающая сторона остаётся подключённой к Durable Object. Durable Object остаётся активным, пока выполняется запрос, RPC-вызов, передача ответа, соединение WebSocket или ожидающая операция ввода-вывода.
Workflows (за шаг)	Без ограничений	Каждый шаг может выполняться неограниченное время. На отдельные шаги распространяется настроенный Лимит времени CPU.