Equipe e plataformaConceito

Inícios aquecidos

Iniciar um interpretador dentro de um sandbox custa tempo antes da primeira linha do seu código rodar. Os workers pagam esse custo antes, fora do caminho crítico, então a tarefa que você inicia encontra um runner já esperando. Nada para ligar e nenhum plano pago: todo script em todo plano tem isso.

6 min de leituraAntes: Workers
O que você vai aprender
  • Saber o que é um runner aquecido e por que cada um ainda atende só uma tarefa
  • Saber quais scripts JavaScript e TypeScript pegam o caminho rápido
  • Entender o que um flow reserva antes de um loop começar
  • Ajustar ou desligar o pool aquecido num worker self-hosted

Um runner já esperando

Cada worker mantém alguns runners aquecidos para Python e para TypeScript/JavaScript: processos que já iniciaram o interpretador dentro do sandbox e estão esperando uma tarefa. Quando uma tarefa é reservada, ela recebe um deles, e um substituto começa a iniciar em segundo plano.

ProjetosWorkers3Usuários
As máquinas que rodam seus scripts e flows. Um worker sem atribuição atende todos os projetos.
Buscar workers…Ctrl KOnline · 3Ocupados · 2ao vivo · atualiza a cada 5s
worker-98142bb7 StatusOnlineVagas3/12Tarefas1,284Média41 msMem212 MBRodando agora report.py
worker-606b8c73 StatusOnlineVagas1/12Tarefas1,197Média38 msMem164 MBRodando agora greet.ts
worker-eb57a201 StatusOnlineVagas0/12Tarefas1,206Média40 msMem98 MBRodando agora—
Cada worker da aba Workers mantém os próprios runners aquecidos; o tempo médio por tarefa em cada cartão reflete isso.

O que fica aquecido

LinguagemComo começa rápido
PythonUm runner já iniciado do pool aquecido.
TypeScript, JavaScriptUm caminho rápido que roda o script num motor dentro do processo quando dá, senão um runner já iniciado.
C, C++O binário compilado fica guardado pelo código, então só a primeira execução compila.
PostgreSQL, MySQLAs conexões com cada banco ficam abertas (até 4 por conexão por worker).

O caminho rápido de JavaScript e TypeScript

Um script pega o caminho rápido quando o bundle dele funciona e ele não importa o SDK waiso. Qualquer outra coisa — um erro de compilação, um erro lançado, um timer ou acesso a arquivo que precisa de um runtime completo — volta para o runner normal, cuja resposta é a que vale. O caminho rápido atende só a versão mais recente do runtime, e código que cita o global Bun nunca pega esse caminho.

fast.ts
// Takes the fast path: plain code, no SDK import.
export async function main(n: number = 10) {
  return Array.from({ length: n }, (_, i) => i * i)
}

Flows reservam antes

Um flow sabe o que vem pela frente. Quando é reservado, e de novo quando cada loop começa, ele pede ao worker runners Python aquecidos suficientes para o pico — o dobro do paralelismo do loop, até um teto —, então as iterações depois da primeira leva começam sem nenhuma inicialização. Medido no nosso ambiente, uma iteração de loop foi de 101 para 45 ms de mediana, sem inícios a frio depois da primeira leva.

O detalhe de uma execução mostra a diferença: um passo que precisou iniciar o runner leva uma marca de início a frio com o tempo que custou. Veja Desempenho para todos os números medidos.

Ajuste (self-hosted)

  • WARM_POOL_BASE — runners aquecidos mantidos por linguagem em repouso (2 por padrão). 0 desliga o pool e cada tarefa inicia o próprio runner.
  • WARM_POOL_RESERVE_MAX — o máximo que um flow pode reservar num worker (8 por padrão, uns 110 MB de Python parado). 0 desliga as reservas.
  • SQL_POOL_MAX_PER_INTEGRATION — conexões abertas por conexão de banco por worker (4 por padrão).

Assuntos relacionados