Template de Relatório de Benchmark da Malha PAEBIRU

Baseado no roteiro de teste do System Design Workbook (Matheus Scarpato Fidelis, ISBN 978-65-02-00869-0). Este template padroniza a documentação de benchmarks Criterion e simulações Python para garantir rastreabilidade, reprodutibilidade e comparabilidade entre releases.

Cabeçalho do Relatório

1. Objetivos e Hipóteses

1.1. Objetivo Principal

Descreva em uma frase o que o benchmark pretende medir (ex: “Determinar a latência p99 do Portão 3 sob 10.000 assinaturas PQC/s”).

1.2. Hipóteses

• H1: O componente sustenta a carga alvo sem degradação > 5%.
• H2: O consumo energético (µJ/op) permanece dentro do orçamento DRE.
• H3: Não há vazamento de memória ou crescimento de fila ao longo de 1h de execução.

1.3. Critérios de Aceitação

2. Metodologia

2.1. Cenário de Teste

Descreva o cenário: carga nominal, pico, stress, soak, spike ou endurance.

2.2. Configuração do Ambiente

# Exemplo de parâmetros documentados
[benchmark]
duration_seconds = 300
warmup_seconds = 30
sample_size = 100

[network]
peer_count = 100
gossip_frequency_hz = 1
partition_simulation = false

[security]
paebiru_gate_security_cost_micro_joules = 50
paebiru_layer9_temperature_threshold = 0.75

2.3. Ferramentas

• Criterion.rs: Versão X.Y.Z — configurações de medição (estatística, tratamento de outliers).
• Simulações Python: Versão do apps/simulations/ — modelo de carga aplicado.
• Observabilidade: Prometheus + Jaeger coletados? Sim / Não.

3. Resultados

3.1. Métricas Brutas

Inclua a saída do Criterion (latência média, desvio padrão, percentis) ou do script Python.

Example: kernel_crypto/verify_ml_dsa
                        time:   [14.892 µs 14.934 µs 14.981 µs]
                        change: [-1.2% -0.8% -0.3%] (p = 0.01 > 0.05)
                        throughput: 66.7 Kops/s

3.2. Gráficos e Distribuições

• Histograma de latência.
• Regressão linear (tendência ao longo das amostras).
• Distribuição de probabilidade (PDF) comparada com baseline.
• Série temporal de throughput (para testes de endurance).

3.3. Comparação com Baseline

Nota: Use o critério p < 0.05 do Criterion para determinar significância estatística.

4. Análise e Interpretação

4.1. Alinhamento com Teoria das Filas (se aplicável)

Para benchmarks de throughput/latência, compute:

• $\lambda$ (taxa de chegada medida).
• $\mu$ (taxa de serviço máxima observada).
• $\rho = \lambda / \mu$ (utilização).
• $W_{\text{teórico}}$ via Lei de Little e compare com $W_{\text{medido}}$.

4.2. Anomalias e Eventos

Registre qualquer evento anômalo: GC pauses, thermal throttling, spikes de latência, erros de rede.

4.3. Conclusão

O componente passou / não passou nos critérios de aceitação. Justifique.

5. Recomendações

• Otimização: Há gargalos identificados? Qual portão/função dominou a latência?
• Capacity Planning: Qual o headroom restante? Em que $\lambda$ o sistema saturaria?
• Próximos Passos: Benchmarks adicionais necessários (ex: escala 10×, cenário com partições).

6. Apêndice

A. Comando de Reprodução

# Comando exato para reproduzir o benchmark
cargo bench -- <nome_do_bench> --verbose
# ou
make docker-bench-single name=<nome_do_bench>

B. Artefatos

• target/criterion/report/index.html
• Logs do Prometheus (snapshot)
• Traces do Jaeger (UUID do trace root)
• Artefatos brutos de simulação Python (apps/simulations/output/)

C. Checklist de Revisão

• Ambiente documentado com precisão (hardware, SO, versões).
• Configurações do benchmark salvas em arquivo versionado.
• Baseline definido e comparável.
• Resultados estatísticos incluem intervalo de confiança.
• Anomalias explicadas ou tickets de follow-up criados.
• Relatório revisado por pelo menos um peer.

Nota: Este template deve ser preenchido para todo benchmark que alimente decisões de release, capacity planning ou otimização de performance. Relatórios incompletos serão rejeitados no review de arquitetura.