Como funciona: do arquivo para o banco, e de volta
Cada tira é um lote de linhas: a importação corta o arquivo e grava nas 5 tabelas, uma transação por lote; a exportação junta as 5 tabelas e remonta o arquivo, que precisa sair idêntico.
Duas medições num servidor de $12
No teste web, 15 implementações servem o mesmo feed social com login, cada uma num droplet de 1 vCPU e 2 GB. No teste de dados, 14 linguagens importam e exportam arquivos pelo PostgreSQL no mesmo perfil de droplet. Cada teste tem sua própria medida.
15linguagens e frameworks
$12por mês na DigitalOcean: 1 vCPU compartilhada, 2 GB
3×cada stack no experimento completo, em hosts diferentes
500 mso p95 que nenhuma pode passar
Ranking 1 · capacidade web
Usuários simultâneos no droplet de $12 com p95 abaixo de 500 ms. Clique numa linguagem para ver as rodadas dela.
3 reproduções oficiais por linguagem, cada uma num host diferente; p99 < 1 s e erros < 1% valem junto com o p95. Como a busca chega na capacidade: a régua, abaixo.
Ranking 2 · transferência de dados
A mediana das 3 execuções de cada linguagem: linhas por segundo para dentro e para fora do banco.
Aqui não há usuários nem p95: um programa só, que lê e grava com a biblioteca padrão da linguagem (só o driver do PostgreSQL vem de fora) e precisa devolver um arquivo idêntico byte a byte.
1Mlinhas para importar (158 MB), num banco com 1M
2Mlinhas exportadas (314 MB), conferidas por SHA-256
5tabelas e 4 chaves estrangeiras
1.000linhas por transação, o mesmo SQL em todas
Medido de fora, igual para todas as linguagens: a importação pela sequência de ids da tabela itens (uma por linha importada), a exportação pelas linhas que já estão no arquivo de saída, uma leitura por segundo. Metodologia completa no README do projeto (§21).
No teste web, o que muda
O mesmo app, as mesmas consultas SQL e a mesma autenticação em cada uma. Muda só a linguagem e o framework. No N0, cada uma atende requisições simultâneas do jeito padrão do seu framework; em laranja, as que têm um teto baixo de requisições ao mesmo tempo (a CPU de cada rodada mostra se foi o teto ou a CPU que limitou).
Como medimos a capacidade web
A mesma régua para todas as stacks, rodada após rodada.
loadgen
s-4vcpu-8gb4 vCPU, 8 GB · só gera a carga, não é medido
k6usuários virtuais, aos milhares
cada usuário virtual repete o ciclo do card 2 (abaixo) e cronometra cada resposta
requisições HTTP, todas com login (JWT)
GET /feed · GET /posts/:id · POST …
respostas em JSON: o k6 mede a latência (p95, p99) e os erros
pela rede privada da DigitalOcean
target
s-1vcpu-2gb1 vCPU, 2 GB · o servidor medido ($12/mês)
- nginxrecebe as requisições
- o appuma das 15 stacks, uma por vez
- PostgreSQL 16o banco: 343 MB, cabe na memória
sar e pidstat medem CPU, memória, disco e rede a cada 5 s
1 a máquina
Droplet de $12 da DigitalOcean: 1 vCPU compartilhada, 2 GB de RAM, sem swap. nginx, o app e o PostgreSQL 16 na mesma máquina, como no vídeo. O banco tem 50 mil usuários, 500 mil posts e 2 milhões de curtidas (343 MB) e é recriado do zero antes de cada rodada.
sem CDN, sem Redis, sem banco gerenciado
2 o usuário
Cada usuário virtual do k6 faz o que uma pessoa faz, em ciclo:
simulação acelerada · tempos reais na lista
- abre o feed
GET /feed - lê3–7 s
- abre um post
GET /posts/:id - lê3–8 s
- curte o post em 15% das voltas
POST /posts/:id/like - publica um post em 2%
POST /posts - pausa5–15 s
- e volta para o feed
uma volta leva ≈ 20 s e faz ≈ 2,2 requisições: ≈ 0,1 requisição por segundo por usuário · todas as rotas com login (JWT)
3 o critério
p95< 500 ms95 de cada 100 respostas em menos de meio segundo
p99< 1 s99 de cada 100 em menos de um segundo
erros< 1%menos de 1 falha em 100
falhou em um, a rodada falha
4 a busca
Começa com 250 usuários e dobra até falhar. Depois refina entre o último que passou e o primeiro que falhou (bissecção, até 10%). No fim, confirma: 3 rodadas de 5 minutos, e as três precisam passar.
O roubo de CPU pelos vizinhos do host é medido a cada 5 s e com a máquina em repouso, e acompanha cada número.
O que rodou: versões
Registradas em cada host pelo infra/versions.sh e nos lockfiles do código; iguais nos três hosts quando só aparece uma.
Onde roda: DigitalOcean
As máquinas são droplets (servidores virtuais) da DigitalOcean, cobrados por segundo ligados. Cada experimento cria dois na mesma região, mede, baixa os resultados e apaga tudo.
tor1, sfo2: de onde vêm esses nomes
É o código da região na DigitalOcean: a cidade abreviada e o número do datacenter dela. tor1 é o primeiro datacenter de Toronto; sfo2, o segundo de San Francisco. Os dois droplets de um experimento ficam no mesmo datacenter e conversam pela rede privada.
quanto custa
o custo de cada experimento vem da fatura da DigitalOcean ou, enquanto ela não fecha, das horas ligadas × o preço por hora
Linha do tempo dos experimentos
Cada bolinha é o experimento de uma linguagem, na ordem em que começou a ser medida. Dentro dele ficam as reproduções: a mesma medição em 3 hosts diferentes, e a capacidade é a mediana delas. Clique para abrir.