Cloudflare додала профілювання CPU та пам’яті для Workers і Durable Objects

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

Як отримати профіль коду, що працює

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

Сенс профілювання в продакшені — побачити, як код працює під реальним навантаженням. Локальний запуск через 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

Про автора

Бруно Матео

Старший fullstack-розробник

Допомагаю командам пришвидшувати інтерфейси й серверні процеси без гонитви за черговим стеком. Якщо потрібно, поясню технічне рішення, не припускаючи, що співрозмовник уже все знає.

Усі публікації автора