Por trás dos
benchmarks.

Use desempenho junto de linguagem, experiência da equipe, manutenção, documentação e suporte. Valide as opções com a carga e o hardware da sua aplicação.

Eles mostram custos diferentes de abstração. Filtre por classe, banco, ORM e plataforma para comparar stacks semelhantes; a tabela completa é propositalmente ampla.

Realistic busca uma configuração de produção de uso geral. Stripped é configurada ou construída para o benchmark e pode ser inadequada como ponto de partida para produção. Stripped começa oculta, como no visualizador original.

A implementação não concluiu a carga com sucesso ou não passou na validação exigida. O teste aparece como falha, sem receber uma pontuação de desempenho. Consulte os logs para investigar.

As cargas disponíveis e implementações mudam entre rodadas. Uma configuração presente no repositório atual não significa que ela foi medida numa publicação histórica.

Hardware, rede, versões de software e implementações mudam com o tempo. Trate cada rodada e ambiente como um experimento separado. Este portal não combina rodadas numa pontuação única.

A vazão publicada usa a duração da rodada e a quantidade de requisições após descontar erros de conexão, leitura, escrita e HTTP 5xx. A latência vem da mesma amostra selecionada. Escolha a quantidade nas cargas de consulta; nas cargas de concorrência, confira todos os níveis e a melhor amostra.

A ferramenta local divide totalRequests pelo tempo medido nos timestamps. O visualizador das rodadas usa a duração publicada e desconta erros. São cálculos diferentes, portanto os valores podem divergir.

Compara uma implementação com a plataforma base explicitamente declarada, no mesmo teste e ambiente. A porcentagem aqui divide RPS do framework por RPS da base. Não inferimos uma base por nome ou linguagem semelhantes.

O procedimento original descreve preparação de 5 segundos com concorrência 8, aquecimento de 15 segundos com 256 e amostras medidas nos níveis da carga. Preparação e aquecimento não entram nas medições publicadas. Confira as configurações ao reproduzir uma execução.

A suíte equilibra o tempo de medição com muitas implementações. Uma execução sintética curta não representa todas as aplicações longas, padrões de GC ou JIT. Amplie a duração e repita as execuções na sua investigação.

wrk é o gerador de carga HTTP com múltiplas threads. Ele envia requisições durante a duração configurada e registra quantidades, latência e erros. A saturação do gerador ou da rede pode limitar a vazão observada.

Consultas em cache são uma carga separada com requisitos próprios. Os testes comuns de banco devem executar as operações exigidas. Respostas servidas por cache reverso externo sem executar a aplicação mudariam o objeto da medição.

As expectativas originais incluem pool de conexões e configurações que utilizem os recursos de CPU disponíveis. Os logs da aplicação geralmente ficam desativados. Revise cada implementação em vez de presumir todos os padrões de produção.

A suíte evolui com contribuições da comunidade. Relate problemas com um exemplo reproduzível ou envie uma alteração com resultados de verificação. Uma rodada publicada continua sendo uma fotografia histórica depois de atualizar o repositório.

Comece pelos requisitos da carga, contribua uma implementação e valide com o executor. Use o fork para mudanças da Better Web e o projeto original para mudanças destinadas às rodadas oficiais da TechEmpower.

TFB Status publica execuções contínuas e logs. Eles ajudam a diagnosticar contribuições e são diferentes das rodadas oficiais publicadas.

O visualizador original começa os dados históricos na rodada 3 porque os primeiros formatos e identificadores mudaram. As duas primeiras publicações continuam disponíveis nos artigos da TechEmpower abaixo.