У changelog Cloudflare описано зміну в тому, як запускаються Durable Objects після періоду бездіяльності. Розберімося, що саме оновили, для кого це помітно і які обмеження залишаються.
Що саме змінила команда Cloudflare
Раніше, коли Durable Object певний час був неактивним, платформа могла запустити його наступного разу на будь-якій підходящій машині в обраній локації даних. Це означало, що стан обʼєкта потрібно було знову завантажувати з диску або іншого сховища в памʼять.
Тепер, за описом Cloudflare, логіка інша: коли обʼєкт «прокидається» після простою, платформа намагається запустити його саме на тій машині, де він працював востаннє. Якщо це вдається, дані обʼєкта не потрібно завантажувати повторно, оскільки вони можуть уже бути в локальному кеші або на локальному диску цієї машини.
Як це впливає на холодні старти
Оновлення особливо помітне для Durable Objects, які використовують SQLite як сховище стану. У changelog окремо наголошено на сценарії, коли обʼєкт стає неактивним і відносно швидко знову отримує трафік.
- Якщо обʼєкт був неактивним недовго, є шанс, що його дані ще доступні локально на тій же машині.
- За новим алгоритмом платформа намагається повернути обʼєкт саме на цю машину.
- У такому випадку повторне зчитування з диску або віддаленого сховища не потрібне, час «холодного старту» скорочується.
Важливе застереження від Cloudflare: фактичний виграш залежить від конкретного робочого навантаження та патернів трафіку. Наприклад:
- Якщо обʼєкт прокидається дуже рідко або після тривалих простоїв, користі може бути небагато, бо дані, імовірно, уже вивантажені з кешу.
- Якщо ваш трафік розподілений по багатьох регіонах та машинах, система може зважити інші фактори (наприклад, близькість до користувача) і не завжди повертати обʼєкт на ту саму машину.
Які виграші можливі для SQLite-backed Durable Objects
Автори changelog окремо згадують Durable Objects, що зберігають стан у SQLite. Для таких обʼєктів сценарій може виглядати так:
- Обʼєкт активно обробляє запити, SQLite-файл прогрітий та вже відкритий.
- Потік запитів падає, обʼєкт стає неактивним і припиняє роботу.
- Через короткий час (наприклад, секунди або хвилини) надходить новий запит.
- Платформа намагається запустити обʼєкт на тій самій машині.
- Якщо ресурси ще не очищені, доступ до даних SQLite може бути швидшим, ніж при повному «холодному» старті на іншому вузлі.
Це не гарантує однакового ефекту для всіх додатків, але для патернів з частими короткими «засинаннями» та «пробудженнями» затримка від повторної активації може зменшитися.
Що потрібно зробити розробникам
У changelog прямо зазначено, що зміна вже розгорнута в усіх регіонах, і клієнтам не потрібно виконувати жодних додаткових дій.
- Не потрібно оновлювати код Durable Object.
- Не потрібно вмикати окремі прапорці чи налаштування.
- Новий алгоритм розміщення для повторних запусків застосовується автоматично.
З практичної точки зору це означає, що якщо ви вже використовуєте Durable Objects зі сховищем на основі SQLite, ви можете спостерігати рідші або менш помітні холодні старти при повторній активації, але стабільних числових гарантій платформа не обіцяє.
Як збирати власні спостереження по продуктивності
Оскільки Cloudflare підкреслює залежність від трафіку та навантаження, має сенс орієнтуватися на власні метрики.
- Якщо у вас уже є логування часу обробки перших запитів після простою, можна порівняти нові значення з історичними.
- Має сенс відстежувати окремо латентність першого запиту до конкретного Durable Object після неактивності, а не лише середній час по всій системі.
- Якщо у вас складна географія трафіку, варто дивитися на різницю між регіонами, оскільки логіка розміщення також враховує розташування користувачів.
Автори оновлення не наводять числових прикладів прискорення, тому оцінку ефекту доведеться будувати на внутрішніх вимірюваннях.
Де почитати про розміщення Durable Objects детальніше
Для глибшого розуміння того, як платформа обирає місце розташування даних, у changelog наводиться посилання на офіційну документацію Cloudflare Durable Objects про розміщення та локацію даних: https://developers.cloudflare.com/durable-objects/reference/data-location/.
Там описано загальні принципи, які діють поряд з новою логікою перезапуску після неактивності, включно з тим, як обираються регіони, як впливають політики розміщення та що може завадити запуску саме на «останній» машині.
Джерело: Cloudflare Changelog