Inicialização a frio do WebAssembly: o que os benchmarks mostram

A inicialização a frio tornou-se mais uma vez um eixo de diferenciação comercial entre os tempos de execução do WebAssembly, e não apenas um assunto de pesquisa acadêmica. Wasmer torna isso um argumento de venda explícito com um recurso chamado Instaboot, apresentado como uma resposta direta ao problema de inicialização a frio.

Esse reflexo lembra exatamente a dinâmica já documentada em nosso artigo sobre a metodologia de backend benchmark : vários fornecedores concorrentes exibem números de desempenho em suas próprias páginas de produto, sem sempre especificar o protocolo que os produziu. Um valor de partida a frio sem método prova nada mais do que um valor de latência sem método.

Uma partida a frio não é uma operação única: é uma soma de fases distintas, e dois fornecedores não medem necessariamente as mesmas fases sob o mesmo nome.

Uma figura que conta apenas a instanciação de um módulo já carregado e já compilado na memória parecerá mecanicamente melhor do que uma figura que inclui carregamento e compilação de rede. Nenhum dos dois é falso em si: o problema surge quando os comparamos sem especificar qual dos dois foi medido.

Trabalhos acadêmicos publicados como pré-impressão no arXiv nos últimos anos mediram o tempo de instanciação de módulos WebAssembly em diferentes tempos de execução. O ponto comum entre esses trabalhos não é um número convergente: é uma diferença significativa dependendo do tempo de execução testado, do tamanho do módulo e do hardware utilizado.

Não incluímos voluntariamente neste artigo quaisquer números precisos retirados dessas publicações. Sem ter verificado minuciosamente a metodologia de cada artigo no momento da redação, republicar um número isolado reproduziria exatamente o problema que este artigo documenta: um número sem o contexto que nos permitiria saber o que ele realmente mede.

O que essa variação aprende, por outro lado, é diretamente útil: uma inicialização a frio depende fortemente do contexto de medição, exatamente como lembrado pela disciplina de paridade de ambiente descrita em nosso artigo de metodologia geral (hardware idêntico, mesma região, mesmo estado de cache para todos os sistemas comparados).

Os três tempos de execução independentes do WebAssembly mais citados neste debate não equilibram a velocidade de compilação e o desempenho de execução da mesma maneira, o que explica em parte por que seus números de inicialização a frio não são comparados termo a termo.

Para obter detalhes completos da arquitetura entre os dois tempos de execução mais frequentemente opostos em discussões sem servidor, consulte nossa comparação dedicada Wasmtime vs Wasmer.

De acordo com o posicionamento do produto que Wasmer comunica publicamente, o Instaboot restaura uma instância já inicializada por um mecanismo de snapshot, em vez de reiniciar uma inicialização completa a cada solicitação. É uma escolha arquitetônica real que é consistente com o problema que visa.

O que este artigo não faz, entretanto, é repetir um número de desempenho exibido na página do produto Wasmer. Sem saber qual hardware, qual carga de trabalho e qual protocolo de medição produziu esse número, republicá-lo cometeria exatamente o erro documentado acima: tratar um número de marketing como um resultado de benchmark independente.

Aurabase executa suas funções Edge no Wasmtime em produção, não em um projeto piloto. Aqui está exatamente o que o pedido permite e onde termina a reivindicação.

A dependência é declarada hard, com os recursos async e cranelift ativados, nas dependências de produção do serviço, não em dev-dependency nem em comentário:

# Extrato real do repositório
[dependencies]

# Tempo de execução WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

O que este arquivo não diz: nenhum valor de partida a frio medido de acordo com o protocolo descrito em nossa metodologia de benchmark existe hoje no repositório para este tempo de execução. Até que uma medição datada, com percentis desagregados, hardware e carga de trabalho, seja publicada, nenhum valor do Aurabase deve ser citado como uma característica medida do produto. Para a arquitetura geral da plataforma, consulte nosso artigo principal Aurabase Rust arquitetura. Para uma comparação concreta entre o WASM de inicialização a frio e o contêiner de inicialização a frio, independente da questão metodológica abordada aqui, consulte nosso artigo dedicado WASM vscontêineres.

Sete perguntas a serem feitas a qualquer figura de partida a frio, incluindo a nossa no dia em que lançarmos uma.

1. Quais fases estão incluídas? Carregamento de rede, validação, compilação, instanciação, primeira chamada: um número que conta apenas parte dela não é comparável a um número que conta todos eles.
2. O módulo estava realmente “frio”? Um módulo já na memória ou cache de disco não testa a mesma coisa que um módulo carregado pela primeira vez.
3. Compilação JIT ou artefato pré-compilado (AOT)? As duas estratégias têm custos iniciais estruturalmente diferentes.
4. Único dígito ou distribuição? Uma melhor execução em dez não tem o mesmo valor que um p95 em mil execuções.
5. Equipamento e região especificados? Uma figura sem especificação de hardware não pode ser reproduzida por terceiros.
6. Comparação com carga e topologia iguais? Comparar um tempo de execução auto-hospedado com um serviço gerenciado sem relatá-lo distorce a leitura.
7. Data e versão do tempo de execução testado? Um número sem data em um projeto que está evoluindo rapidamente não significa nada depois de alguns meses.