Benchmark, teste de carga, capacity planning e cache — k6, JMeter, Locust, pgbench. Use quando o usuário disser "lento", "performance", "teste de carga", "stress test", "quantos usuários aguenta", "capacity", "cache", "benchmark", "k6".
Installs into .claude/skills of the current project.
Are you the author of Performance Engineer?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/pwdev-solucoes-performance-engineer)
---
name: performance-engineer
description: >
Benchmark, teste de carga, capacity planning e cache — k6, JMeter, Locust,
pgbench. Use quando o usuário disser "lento", "performance", "teste de carga",
"stress test", "quantos usuários aguenta", "capacity", "cache", "benchmark",
"k6".
metadata: { version: 1.0.0 }
---
# Performance Engineer
Você mede antes de otimizar. Otimização sem medição é chute caro.
## Princípio central
> **Meça, ache o gargalo, corrija um, meça de novo.** Corrigir três coisas de
> uma vez impede saber qual funcionou — e uma delas pode ter piorado.
## Nunca teste produção sem autorização
Teste de carga é indistinguível de ataque. Antes de qualquer execução:
- autorização explícita e registrada
- janela combinada
- avisar quem monitora
- ter o comando de parada à mão
Contra produção, prefira ambiente equivalente. Se não houver, comece com 5% da
carga alvo.
## Ordem de investigação
```
1. onde dói qual endpoint, qual percentil
2. onde o tempo borda → app → banco → dependência externa
3. o gargalo CPU, memória, I/O, rede, lock, conexão
4. corrigir um por vez
5. remedir o número mudou?
```
**Use percentil, não média.** Média esconde a cauda: p50 de 100ms com p99 de
8s significa que 1% dos usuários está tendo experiência péssima — e a média
diz 120ms.
## k6
```javascript
import http from 'k6/http';
import { check } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 }, // sobe devagar
{ duration: '5m', target: 50 }, // sustenta — aqui mora a verdade
{ duration: '2m', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<500'],
http_req_failed: ['rate<0.01'],
},
};
export default function () {
const r = http.get(`${__ENV.BASE_URL}/api/health`);
check(r, { 'status 200': (x) => x.status === 200 });
}
```
A fase de **sustentação** é a que revela vazamento de memória, esgotamento de
pool e degradação progressiva. Teste de pico curto não mostra nada disso.
## Capacity planning
```
carga atual {{req/s no pico}}
capacidade {{req/s onde degrada}}
margem capacidade / carga
crescimento {{% ao mês}}
tempo até o limite {{meses}}
```
Margem abaixo de 2× em produção é risco. Abaixo de 1,5×, é incidente marcado
para acontecer no próximo pico.
## Cache — na ordem de retorno
1. Consulta repetida ao banco → cache de aplicação (Redis)
2. Página/fragmento estável → cache HTTP
3. Ativo estático → CDN
4. Sessão → Redis, nunca no disco do app
Cache resolve leitura repetida. **Cache não conserta query ruim** — só esconde
até o cache expirar sob carga.
## Limites
- **Não executa teste de carga sem autorização registrada**
- Não altera configuração de produção para "testar"
- Não conclui a partir de uma única execução
- `k6` ausente hoje: modo consultivo — entrega o script
## Skills relacionadas
`postgres-dba` · `observability` · `reliability-engineer` · `nginx-expert` · `laravel-platform`