O prewarming no Laravel Vapor reduz cold starts, o que é crítico para aplicações serverless. Quando você faz deploy, nenhum container Lambda está aquecido e pronto para processar requisições por padrão. Isso leva a cold starts garantidos que podem adicionar até 2 segundos aos tempos de resposta. O prewarming envia requisições para um número especificado de containers no deploy e continua fazendo ping a cada 5 minutos para mantê-los aquecidos.

Quanto Prewarming Você Precisa?

Considere um droplet de $5/mês na DigitalOcean com 1GB de memória. Se cada requisição Laravel usa aproximadamente 25MB, o droplet pode teoricamente lidar com cerca de 40 requisições concorrentes (assumindo que toda a memória é alocada para o PHP).

Para igualar essa concorrência no Vapor, você precisaria de 40 containers Lambda aquecidos. A boa notícia: isso não é caro.

Comparação de Custos

Preços do AWS Lambda em US East (N. Virginia):

Custo de duração: $0,0000166667 por GB-segundo
Custo de requisição: $0,20 por milhão de requisições

Para uma função Lambda com 1024MB de memória:

Um ping de prewarm roda aproximadamente a cada 5 minutos
40 containers x 12 pings/hora x 24 horas = 11.520 requisições por dia
Mensal: ~345.600 requisições
Custo de requisições: aproximadamente $0,07/mês
Custo de duração (assumindo 100ms por ping): aproximadamente $0,06/mês

Custo total de prewarming para 40 containers: aproximadamente $0,13/mês -- dramaticamente mais barato do que até o VPS mais básico.

Configurando o Prewarming no Vapor

No seu arquivo de configuração vapor.yml, defina o valor warm para cada ambiente:

environments:
  production:
    warm: 40

Isso diz ao Vapor para manter 40 containers aquecidos o tempo todo.

Quando Aumentar o Prewarming

Monitore os padrões de concorrência da sua aplicação. Se você notar cold starts durante períodos de pico de tráfego, aumente a contagem de warm. Gatilhos comuns incluem:

Campanhas de marketing que geram picos repentinos de tráfego
Disparos de email que enviam muitos usuários ao seu site simultaneamente
Padrões de tráfego baseados em fuso horário onde horários de pico exigem mais capacidade

Prewarming vs. Concorrência Provisionada

A AWS também oferece Concorrência Provisionada como alternativa ao prewarming. Isso mantém as funções Lambda inicializadas e prontas para responder em milissegundos de dois dígitos. No entanto, a Concorrência Provisionada é significativamente mais cara do que a abordagem de prewarming do Vapor e tipicamente só é necessária para aplicações críticas em latência onde até cold starts ocasionais são inaceitáveis.

Melhores Práticas

Sempre faça prewarm de ambientes de produção. Não há boa razão para pular o prewarming dado o custo desprezível.
Defina valores de warm baseados no uso concorrente típico, não no tráfego de pico. O auto-scaling lida com tráfego burst; o prewarming lida com a carga base.
Monitore taxas de cold start através de métricas do CloudWatch para ajustar sua contagem de warm ao longo do tempo.
Considere deploys separados para diferentes cargas de trabalho (requisições web vs. workers de fila) com configurações de prewarming independentes.

O prewarming é uma das otimizações mais simples e baratas que você pode fazer para uma aplicação Laravel serverless. Por centavos ao mês, você elimina a reclamação mais comum sobre arquiteturas serverless: a latência de cold start.