Relatório de Desempenho

Projeções para servidor com 2 vCPUs, 1 GB RAM, 10 GB SSD.

1.200

req/s máx

conexões simultâneas

150k

visitas/dia

2–4 ms

bootstrap (OPcache)

Throughput (req/s)

JSON

1.200

View + Layout

750

1 query DB

500

Auth completo

400

Upload (POST)

250

Latência (ms, p50)

JSON

3 ms

View + Layout

6 ms

1 query DB

12 ms

Auth completo

20 ms

Memória por worker PHP-FPM

Idle

28 MB

Req sem DB

34 MB

Req com DB

43 MB

Pico

50 MB

Pool recomendado: pm.max_children = 15 (≈525 MB para PHP-FPM)

Capacidade de visitas (por dia)

API REST

150k

Site institucional

100k

Loja virtual

60k

Painel admin

15k

Resiliência a pico (1.000 req em 1s)

750 ms

tempo para absorver

135

fila máxima

50 ms

espera máxima em fila

30 s

até saturação total

Espaço em disco (deploy produção)

Fonte (core+libs+app+config+public+CLI)

752 KB

Deploy produção (com vendor --no-dev)

880 KB

≈14.000 linhas de código. Menos de 1 MB em produção.

Consumo de memória no servidor (1 GB RAM)

OS 200 MB

MySQL 250 MB

Nginx 25 MB

PHP-FPM 400 MB

Buffer 100 MB

Observações

Bootstrap do framework em 2–4 ms com OPcache — sem service providers ou injeção automática
15–25 arquivos carregados por requisição (vs centenas em soluções mais pesadas)
Cache de config e rotas com php blumiga cache:config e php blumiga cache:route
Page cache para rotas públicas reduz carga do PHP em até 90%
Query cache com TTL adequado para consultas lentas

Conclusão

O Blumiga suporta tranquilamente um servidor com 2 vCPUs, 1 GB RAM e 10 GB SSD para a maioria dos cenários de produção. Enquanto alguns outros frameworks exigem servidores com 4+ vCPUs e 4+ GB RAM para manter desempenho aceitável, o Blumiga opera com folga nos recursos apresentados — entregando até 1.200 req/s e suportando 150 mil visitas/dia sem degradação. O baixo consumo de memória (~50 MB por worker) permite mais processos PHP-FPM simultâneos, resultando em melhor concorrência e menor latência.