Бюджет холодного старта: куда уходят 400 миллисекунд

«Холодный старт» — не одна операция, а пять последовательных стадий. Оптимизировать имеет смысл только те, что занимают заметную долю.

Разбивка

Видно главное: для Node.js 60% бюджета — инициализация самого приложения. Никакая работа платформы это не исправит.

Что делает платформа

Мы держим пул прогретых микро-ВМ на каждом узле. ВМ создана, ядро загружено, но rootfs не примонтирован. Старт из пула — 6 мс вместо 42.

Образы раскладываются по слоям и кешируются на узлах региона. Попадание в кеш — 94% в median-регионе; промах стоит дополнительные 120–400 мс в зависимости от размера.

Что можете сделать вы

Ленивая инициализация

Самое дешёвое улучшение: не устанавливать соединения к БД и не читать конфигурацию до того, как они понадобились.

// было: пул создаётся при импорте модуля, +180 мс к старту
// const pool = new Pool({ connectionString: process.env.DATABASE_URL });

// стало: пул создаётся при первом обращении
let pool;

export function db() {
  if (!pool) {
    pool = new Pool({ connectionString: process.env.DATABASE_URL });
  }
  return pool;
}

Меньше зависимостей в горячем пути

У одного из наших клиентов 140 мс старта уходило на импорт библиотеки валидации, которая использовалась в двух обработчиках из сорока. Динамический импорт снял их полностью.

Размер образа

Разница между 40 МБ и 400 МБ — это примерно 90 мс на промахе кеша. Многоступенчатая сборка почти всегда окупается.

FROM golang:1.26 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /out/app ./cmd/api

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
ENTRYPOINT ["/app"]

Когда холодный старт не проблема

При scale.min = 1 его просто нет. Один постоянно работающий инстанс small стоит меньше, чем время команды, потраченное на оптимизацию инициализации. Мы регулярно советуем клиентам начать с этого и вернуться к оптимизации, когда она действительно станет нужна.