Cloudflare добавила профилирование CPU и памяти для Workers и Durable Objects

9 октября 2026 года Cloudflare представила профилирование CPU и памяти для Workers и Durable Objects, работающих в production. Как пишет The Cloudflare Blog, разработчик может запросить профиль активного Worker, изучить результат на интерактивном flamegraph и скачать файл для дальнейшего анализа. Это помогает искать функции, на которые уходит процессорное время или в которых выделяется память, когда общих метрик и логов недостаточно.

Как получить профиль работающего кода

Запустить профилирование можно из вкладки Observability в панели Cloudflare или через CLI. В панели нужно выбрать Worker, тип профиля — CPU или память — и длительность сбора данных. Там же можно указать версию Worker. После записи появляется flamegraph: каждый прямоугольник соответствует вызову функции. Ширина прямоугольника отражает затраты процессорного времени или памяти на функцию. На функции можно нажимать, чтобы рассмотреть их подробнее. Таблица помогает найти функции, которые чаще всего встречаются в профиле.

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

Для Durable Objects можно выбрать по имени конкретный объект. В отличие от обычных Workers, эти объекты хранят состояние и могут перемещаться, поэтому запрос на профилирование направляется к серверу, где работает нужный экземпляр. При записи CPU-профиля выполнение Worker не останавливается на всё время наблюдения: среда запуска освобождает блокировку между началом и завершением сбора, чтобы обычные запросы продолжали выполняться.

Если Worker написан на TypeScript, Cloudflare советует включить source maps. Иначе в профиле могут оказаться непонятные имена функций: график будет доступен, но разобраться, каким участкам исходного кода они соответствуют, станет сложнее.

Что показали внутренние проверки Cloudflare

На Worker, который обслуживает привязку к R2, команда записала CPU-профиль длительностью 50 секунд. В таблице выделилась функция genericR2JsonReplacer: на неё приходилось более 5% процессорного времени. Профиль показал повторную обработку вложенных значений: функцию вызывал JSON.stringify, а она сама дополнительно обходила дерево. После устранения лишней работы эта функция стала быстрее в 2,7 раза.

Тот же профиль помог обнаружить повторный вызов metrics. Один вызов занимал 1% процессорного времени; сохранение результата первого вызова позволило не выполнять тяжёлую операцию второй раз. Это небольшие изменения в коде, которые было проще обосновать, когда появилась картина затрат по функциям.

В другом Worker проблему создавали выделения памяти. Показатель P999 доходил до 133 МБ при лимите 128 МБ, из-за чего Worker часто завершал работу с ошибкой превышения памяти. Профиль показал, что примерно 66,7% выделений приходилось на код Prometheus. Команда считала его отключённым, но часть кода продолжала работать. После полного удаления этого участка P999 снизился до 118 МБ, а P50 — с 70 до 54 МБ.

Что это значит для проектов на Workers

Для разработчика главное изменение — возможность перейти от вопроса «почему выросло потребление ресурсов?» к проверке конкретных вызовов в работающем коде. Это полезно, когда проблема проявляется только при реальном потоке запросов или затрагивает определённый Durable Object. Профиль можно изучить в панели либо скачать и разобрать отдельно.

Владельцу сайта или маркетологу не нужно читать flamegraph, чтобы понимать пользу подхода: команда получает более предметные данные для работы над серверной производительностью. Но результат не появляется автоматически. Профилирование надо запустить вручную, а профиль памяти охватывает только выделения за выбранный промежуток. Если проблема случилась раньше или память активно выделялась при запуске Worker, такая запись её не покажет.

Cloudflare уже работает над непрерывным профилированием: предполагается, что образцы будут собираться автоматически и их можно будет изучать в панели. Срок запуска в анонсе не указан. Пока редкие проблемы можно пропустить, если не успеть начать запись в нужный момент.

Моё мнение: сначала измерить, потом менять

Мне нравится, что инструмент показывает затраты на уровне функций под рабочей нагрузкой. В примерах Cloudflare проблема была не в выборе стека, а в повторном обходе данных, лишнем вызове и коде, который отключили не полностью. Такой профиль помогает обсуждать конкретную правку вместо догадок.

Я бы при этом не принимал один flamegraph за готовое продуктовое решение. Он показывает, где тратятся ресурсы в выбранное время, но команде всё равно нужно решить, что исправлять первым и как проверить результат. Ограничение по времени записи здесь особенно важно помнить.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects blog.cloudflare.com

Об авторе

Бруно Матео

senior fullstack-разработчик

Помогаю командам ускорять интерфейсы и серверные процессы без гонки за очередным стеком. Если нужно, объясню техническое решение без предположения, что собеседник уже всё знает.

Все публикации автора