APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Volume diário, taxa de pico e concorrência descrevem dimensões diferentes. Dividir pedidos pelo número de segundos dá uma média, não o pico que o sistema deve suportar. Define mistura de operações, tamanho dos dados, concentração temporal e dependências. Latência média pode esconder uma cauda longa que afeta os utilizadores mais lentos. Um objetivo de percentil exige medir a distribuição correspondente. Mais réplicas só acrescentam capacidade útil se o trabalho puder ser distribuído e as dependências não se tornarem o novo limite. Liga dimensionamento a quotas, ligações, memória, armazenamento e tempo necessário para escalar, incluindo capacidade durante falhas.
Aplicação guiada
Num exercício original, cada instância foi validada para 150 pedidos/s com a mistura prevista. O pico é 1200 pedidos/s. Sob a hipótese explícita de distribuição uniforme e capacidade linear, são necessárias oito instâncias ativas; para perder uma e manter essa capacidade, são nove provisionadas. Isto não substitui ensaio nem margem adicional. Um teste de carga avalia o volume esperado; stress procura limites; spike avalia subida abrupta; soak procura degradação ao longo do tempo. Compara variantes com dados e tráfego equivalentes, mede erros e latência além de CPU e documenta o que foi simulado. Uma dependência simulada sem atraso pode esconder o principal limite do percurso real.
1200÷150=8 instâncias ativas; tolerar a perda de uma exige 9 sob as hipóteses dadas.
Armadilhas comuns
Média diária como pico; CPU como único limite; capacidade linear presumida; teste curto como prova contra fugas de memória.
Tópicos relacionados: Requisitos e decisões de arquitetura · Dados e consistência · Cache, partições e filas
Declara as hipóteses e mede o percurso que precisa de cumprir o objetivo.
Referência: Architecture strategies for performance testing · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30